Vérifier les en-têtes CORS

Collez un bloc d’en-têtes pour confirmer la présence d’Access-Control-Allow-Origin, détecter l’association dangereuse d’une origine générique avec des identifiants et signaler l’absence de Vary: Origin lorsqu’une origine précise est autorisée. Le résultat est déterministe et explique chaque constat. Il convient donc aux revues de déploiement, aux analyses d’incident, aux contrôles automatisés et au renforcement courant des API, sans envoyer de requête au serveur cible.

Interprétez le résultat comme une vérification ciblée

Commencez par copier les en-têtes de réponse exactement tels que le navigateur ou le client en ligne de commande les a reçus, à raison d’une paire Nom: valeur par ligne. La casse des noms est ignorée et les valeurs Vary séparées par des virgules sont traitées comme des éléments distincts. Le vérificateur exige Access-Control-Allow-Origin, car aucun règlement CORS de réponse ne peut être évalué sans cet en-tête ; son absence produit donc une erreur de saisie plutôt qu’un rapport indéterminé. Un rapport réussi renvoie l’origine autorisée normalisée, l’état d’activation des identifiants, la variation éventuelle de la réponse selon Origin et une liste ordonnée des constats. Le champ valid signifie qu’aucun problème de gravité error n’a été détecté. Un avertissement peut néanmoins subsister : les systèmes consommateurs doivent donc aussi examiner issue_count et issues. Cette portée limitée est volontaire. Elle fournit des faits stables sur deux erreurs fréquentes sans prétendre certifier l’ensemble du modèle d’autorisation de l’application. Conservez la réponse originale et l’origine de la requête avec le résultat si ce contrôle alimente une piste d’audit.

Comprenez l’origine générique et les requêtes authentifiées

Access-Control-Allow-Origin: * convient aux ressources réellement publiques qui n’utilisent pas d’identifiants, puisqu’il permet à toute origine demandeuse de lire la réponse. Il ne doit pas être associé à Access-Control-Allow-Credentials: true. Les navigateurs refusent cette combinaison pour un accès CORS avec identifiants, et cette configuration révèle souvent que le serveur n’a pas correctement exprimé la frontière de confiance voulue. Le vérificateur l’enregistre sous wildcard_origin_with_credentials avec la gravité error. La correction ne consiste pas à renvoyer automatiquement chaque Origin reçu. Déterminez les origines fiables, comparez l’Origin de la requête à une liste d’autorisation explicite et n’émettez une origine approuvée qu’après concordance. Si les cookies ou d’autres identifiants ambiants sont inutiles, désactivez leur prise en charge et conservez la règle publique générique. Gardez aussi à l’esprit que CORS détermine si les scripts du navigateur peuvent lire une réponse ; ce mécanisme ne remplace ni l’authentification, ni l’autorisation, ni la protection contre la falsification de requête, ni un pare-feu. Examinez séparément les attributs des cookies, les contrôles d’accès, les méthodes, les en-têtes exposés et les requêtes préliminaires.

Utilisez Vary: Origin pour fiabiliser les caches partagés

Lorsqu’un serveur choisit une valeur précise d’Access-Control-Allow-Origin en fonction de l’Origin de la requête, la représentation de la réponse dépend effectivement de cet en-tête. Vary: Origin indique aux navigateurs, aux mandataires inverses et aux réseaux de diffusion que les réponses produites pour des origines différentes ne sont pas interchangeables. Sans cette indication, un cache peut réutiliser pour une autre requête une réponse qui porte l’origine autorisée d’un locataire, ce qui cause des pannes intermittentes et peut fragiliser les hypothèses de sécurité relatives au contenu mis en cache. Le vérificateur émet donc missing_vary_origin lorsque l’origine autorisée est précise et que Vary ne contient ni Origin ni le jeton générique. Il accepte Origin dans une ligne Vary à valeurs séparées par des virgules ainsi que dans plusieurs en-têtes Vary. Le constat reste un avertissement, car une réponse collée ne permet pas de savoir si l’origine est constante pour toutes les requêtes ou si la mise en cache est désactivée ailleurs. Vérifiez la logique réelle du serveur et ses directives de cache avant de modifier la production. Si l’origine est reflétée dynamiquement après contrôle d’une liste d’autorisation, ajouter Origin à Vary constitue généralement le signal le plus clair et le plus sûr.