Comprendre le fonctionnement du mécanisme CORS
Le mécanisme de partage de ressources entre origines multiples (CORS, pour Cross-Origin Resource Sharing) est une sécurité essentielle implémentée par les navigateurs web. Il détermine si le code exécuté dans un navigateur est autorisé à lire une réponse provenant d'une origine différente de celle du site actif.
Pour valider ces requêtes, le navigateur s'appuie sur des en-têtes de réponse HTTP spécifiques renvoyés par le serveur. Le processus varie selon la nature de la requête: une requête directe utilise la réponse réelle, tandis qu'une requête nécessitant une validation préalable utilise une réponse de contrôle en amont (requête OPTIONS ou preflight). Cette dernière permet de vérifier si la méthode HTTP et les en-têtes personnalisés envisagés sont acceptés avant d'exécuter la véritable transaction.
Les paramètres d'entrée pour l'analyse
Pour évaluer la conformité d'une politique CORS, plusieurs paramètres précis doivent être fournis au simulateur:
- Réponse à vérifier: Vous devez choisir entre « Réponse réelle » ou « Réponse de contrôle en amont ».
- En-têtes de réponse HTTP: Ce champ de texte accueille les en-têtes renvoyés par votre serveur, incluant la ligne d'état HTTP (particulièrement requise pour les réponses de contrôle en amont). La taille maximale de cette saisie est fixée à 200 000 caractères.
- Origine de la demande: L'origine correspond au schéma, à l'hôte et au port facultatif (par exemple,
https://app.example.com). Elle doit être pure ou égale ànull, excluant tout chemin d'accès, paramètre de requête ou identifiant. - Méthode demandée: Le jeton de la méthode HTTP (comme
GETouPOST) que le navigateur souhaite exécuter. - Noms d'en-tête demandés: Les en-têtes qui apparaîtront dans le champ
Access-Control-Request-Headers, séparés par des virgules ou des retours à la ligne (par exemple,Content-Type, Authorization). - Inclure les informations d'identification: Une option à activer si la requête transmet des cookies ou utilise une authentification HTTP.
Les règles de validation et cas particuliers
L'évaluation des en-têtes CORS obéit à des règles strictes définies par les standards du Web:
La gestion des informations d'identification (Credentials)
Lorsque la requête inclut des identifiants ou des cookies, les règles deviennent beaucoup plus restrictives:
- L'en-tête
Access-Control-Allow-Originne peut pas utiliser le caractère générique*. Il doit correspondre exactement à l'origine de la demande. - L'en-tête
Access-Control-Allow-Credentialsdoit être explicitement défini àtrue. - Les caractères génériques
*présents dansAccess-Control-Allow-MethodsetAccess-Control-Allow-Headersperdent leur fonction de joker et sont traités comme de simples valeurs textuelles.
Les restrictions sur les caractères génériques et l'en-tête Authorization
En l'absence d'informations d'identification, le caractère générique * est généralement accepté pour approuver globalement les méthodes et les en-têtes. Toutefois, l'en-tête Authorization fait exception à cette règle. Même si le serveur renvoie Access-Control-Allow-Headers: *, l'en-tête Authorization doit obligatoirement être listé de manière explicite pour être autorisé.
Validité de la syntaxe des en-têtes
Si l'en-tête Access-Control-Allow-Origin contient plusieurs valeurs ou s'il présente une liste séparée par des virgules, la configuration est considérée comme invalide et la requête sera bloquée par le navigateur.
Interprétation des décisions du navigateur
Après analyse des données saisies, le système affiche l'un des statuts de décision suivants:
- Autorisé par la réponse CORS collée.: Les en-têtes et les paramètres de la requête respectent parfaitement les règles de sécurité.
- Bloqué par la réponse CORS collée.: Au moins un paramètre ou en-tête enfreint la politique CORS.
- Les en-têtes réussissent, mais l'état du contrôle en amont est inconnu.: Les en-têtes sont valides, mais l'absence de ligne d'état HTTP empêche de confirmer le succès de la phase de pré-vérification.
Le système affiche également les champs de contrôle d'accès analysés (Access-Control-*) ainsi que les motifs détaillés de sa décision. Par exemple, il peut indiquer si Access-Control-Allow-Origin correspond exactement à l'origine, si le statut de contrôle en amont est un succès (statut 2xx), ou si une méthode est sécurisée (méthode faisant partie de la liste de sécurité CORS ne nécessitant pas de validation préalable).
Gestion des erreurs de saisie
Le simulateur valide rigoureusement la structure de vos données et peut renvoyer les messages d'erreur suivants:
| Élément en cause | Message d'erreur affiché |
|---|---|
| En-têtes vides | « Collez les en-têtes de réponse HTTP avant de vérifier. » |
| Volume de texte | « Cette réponse est inhabituellement grande. Conservez-le sous les caractères ‹max›. » |
| Ligne d'en-tête malformée | « La ligne ‹line› n'est pas un en-tête ou une ligne d'état HTTP valide. » |
| Nom d'en-tête invalide | « La ligne ‹line› contient un nom d'en-tête HTTP non valide. » |
| Origine incorrecte | « Entrez une origine avec uniquement un schéma, un hôte et un port facultatif, tel que https://app.example.com. » |
| Méthode invalide | « Entrez un jeton de méthode HTTP valide. » |
| Méthode interdite | « Les navigateurs n'autorisent pas la méthode ‹method› dans les requêtes fetch. » |
| En-tête de requête invalide | « « ‹header› » n'est pas un nom d'en-tête de demande HTTP valide. » |
| Erreur générale | « Corrigez l'entrée en surbrillance et réessayez. » |
Confidentialité et traitement des données
La sécurité de vos données techniques est préservée lors de l'utilisation de cet outil. L'analyse 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.
L'outil n'effectue aucun appel réseau externe: il ne contacte pas le serveur, ne lit pas les URL distantes, ne définit pas de cookies, ne vérifie pas les configurations DNS/TLS et ne modifie pas la configuration de vos serveurs.
Foire aux questions
Dois-je coller la réponse réelle ou la réponse de contrôle en amont?
Utilisez la 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.