Vérificateur CORS

Le Cross-Origin Resource Sharing (CORS) est un mécanisme de sécurité essentiel appliqué par les navigateurs web pour contrôler l'accès aux ressources situées en dehors de l'origine d'origine. Le fonctionnement de cette politique repose sur l'analyse d'en-têtes HTTP spécifiques renvoyés par le serveur.

Le fonctionnement du navigateur varie selon le type de requête et la présence d'identifiants. L'outil d'analyse permet de simuler ces règles de validation directement depuis votre navigateur afin de déterminer si une requête cross-origin spécifique sera acceptée ou rejetée.

Fonctionnement de la validation CORS

Pour évaluer la conformité d'une transaction, le navigateur confronte les détails de la requête planifiée aux en-têtes de la réponse HTTP fournie. Le processus d'évaluation repose sur plusieurs critères précis:

• L'origine de la demande: Le navigateur compare l'en-tête Origin envoyé par le client avec la valeur de l'en-tête Access-Control-Allow-Origin de la réponse.
• La méthode HTTP: Pour les requêtes soumises à une pré-vérification, la méthode (comme POST, PUT ou DELETE) doit être explicitement autorisée.
• Les en-têtes personnalisés: Les en-têtes de requête non standards doivent être validés par le serveur lors de la phase préliminaire.
• Les informations d'identification: L'inclusion de cookies ou d'une authentification HTTP modifie radicalement les règles d'acceptation des caractères génériques.

Le traitement de ces vérifications s'effectue localement: vos en-têtes et détails de demande restent dans votre navigateur. Rien n'est téléchargé ou enregistré par BroBroGo.

Analyse de la réponse réelle et de la réponse de pré-vérification

Le protocole CORS distingue deux types de réponses HTTP, qui doivent être analysées séparément selon le contexte de la requête:

La réponse réelle

Elle correspond à la réponse finale contenant les données demandées. Le navigateur vérifie principalement si l'origine de la requête est autorisée à lire le contenu de cette réponse via l'en-tête Access-Control-Allow-Origin. Si cet en-tête est manquant ou ne correspond pas à l'origine, le navigateur bloque l'accès aux données, même si le serveur a traité la requête avec succès.

La réponse avant le vol

Pour les requêtes dites "non-sécurisées" (par exemple, l'utilisation de méthodes comme PUT ou l'envoi d'en-têtes personnalisés), le navigateur émet d'abord une requête préliminaire avec la méthode OPTIONS. Le serveur doit y répondre par un statut HTTP de la série 2xx. Cette réponse de pré-vérification doit contenir les en-têtes autorisant la méthode (Access-Control-Allow-Methods) et les en-têtes de requête (Access-Control-Allow-Headers).

L'impact des informations d'identification sur la politique CORS

L'activation de l'option pour inclure des informations d'identification (cookies ou authentification HTTP) restreint fortement la souplesse des configurations CORS acceptées par le navigateur:

1. Interdiction du caractère générique pour l'origine: Lorsque les informations d'identification sont incluses, l'en-tête Access-Control-Allow-Origin ne peut pas être *. Il doit correspondre exactement à l'origine de la demande.
2. Perte de l'effet joker pour les méthodes et en-têtes: Les caractères génériques pour les méthodes et les en-têtes autorisés perdent également leur signification de caractère générique. Chaque méthode et en-tête doit être listé explicitement.
3. Obligation d'approbation explicite: L'en-tête Access-Control-Allow-Credentials doit être présent et sa valeur doit être exactement true. Dans le cas contraire, la requête est bloquée.

Gestion des méthodes et des en-têtes dans les requêtes Preflight

Lors d'une requête de pré-vérification, le navigateur valide la méthode et les en-têtes demandés:

• Méthodes simplifiées: Les méthodes figurant sur la liste sécurisée CORS (comme GET ou POST sous certaines conditions) n'ont pas besoin d'apparaître dans Access-Control-Allow-Methods.
• Le cas spécifique de l'en-tête Authorization: Cet en-tête requiert une attention particulière. Même si le serveur renvoie Access-Control-Allow-Headers: * pour une requête sans identifiants, l'en-tête Authorization doit obligatoirement être répertorié de manière explicite dans la liste des en-têtes autorisés.

Limites de l'analyse statique des en-têtes

L'évaluation réalisée par cet outil se base uniquement sur les en-têtes textuels saisis et les paramètres de requête configurés. Elle ne simule pas l'intégralité de la chaîne réseau.

Un résultat positif indique la validité théorique des en-têtes fournis, mais ne garantit pas le succès d'une requête réelle. Des facteurs externes tels que des redirections HTTP, des politiques de mise en cache, des modifications dynamiques des règles du serveur, des extensions de navigateur ou le contenu de la réponse réelle finale après un contrôle en amont peuvent modifier le comportement du navigateur en situation réelle.

FAQ (Foire aux questions)

Dois-je coller la réponse réelle ou la réponse de contrôle en amont?

Utilisez Réponse réelle pour vérifier si le code du navigateur peut lire une réponse. Utilisez la réponse Preflight pour la réponse OPTIONS qui approuve une méthode ultérieure et ses noms d'en-tête demandés.

Pourquoi un caractère générique peut-il échouer avec les informations d'identification?

Lorsque les cookies ou l'authentification HTTP sont inclus, l'origine autorisée doit correspondre exactement à l'origine demandeuse. Les caractères génériques pour les méthodes et les en-têtes autorisés perdent également leur signification de caractère générique.

Un résultat positif prouve-t-il que la requête en direct fonctionnera?

Non. Ce résultat couvre uniquement la réponse collée et les détails de la demande saisis ici. Les redirections, les réponses mises en cache, la modification des règles du serveur, les extensions de navigateur et la réponse réelle après un contrôle en amont peuvent toujours modifier le résultat.

Comment est géré l'en-tête Authorization avec le caractère générique *?

L'en-tête Authorization doit être répertorié explicitement dans Access-Control-Allow-Headers. Le caractère générique * ne suffit pas à couvrir cet en-tête spécifique, même pour les requêtes n'incluant pas d'informations d'identification.