C'est le diagnostic d'une requête, pas un vidage d'en-têtes. Vous décrivez l'appel que fait votre code - le point de terminaison, l'origine sur laquelle il s'exécute, la méthode, les en-têtes qu'il pose, s'il envoie des identifiants - et l'outil dit si un navigateur vous laisserait lire la réponse, et quel contrôle précis en a décidé.
Ce qui se passe réellement pendant une analyse
- Préparer la requête exactement comme décrite.
- Classer la requête comme simple ou soumise à préambule, selon les règles du standard Fetch qu'applique un navigateur.
- Tester le préambule avec une vraie requête OPTIONS portant Origin, Access-Control-Request-Method et, si nécessaire, Access-Control-Request-Headers.
- Envoyer la vraie requête, car le préambule seul ne montre jamais les en-têtes CORS de la vraie réponse.
- Sonder la liste d'origines autorisées avec une requête supplémentaire portant une origine que le serveur n'a jamais vue.
- Construire le rapport : verdict, déroulé de la requête, en-têtes, constats et échange technique.
Le sondage de la liste d'autorisation
Un serveur qui répond à chaque origine par cette même origine paraît identique à une liste d'autorisation correctement configurée si vous ne testez jamais que la vôtre. Une requête depuis une origine que le serveur n'a jamais vue sépare les deux cas, et cela compte, car un serveur qui renvoie l'origine en écho, combiné à des identifiants, est exactement la configuration qui rend une réponse lisible par tous les sites que visite son utilisateur.
Les identifiants changent les règles
| En-tête | Avec identifiants |
|---|
| Access-Control-Allow-OriginPas d'astérisque | Doit nommer l'origine. Un astérisque est refusé net, même à côté d'Access-Control-Allow-Credentials: true. |
| Allow-Methods, Allow-Headers, Expose-HeadersLittéral | Un astérisque cesse d'être un joker et se lit comme un nom littéral d'en-tête ou de méthode. |
| Access-Control-Allow-CredentialsObligatoire | Sa seule valeur acceptée est la chaîne exacte true, en minuscules. |
Des constats, pas des adjectifs
Chaque constat porte une gravité, une catégorie, la phase dont il vient, la preuve sur laquelle il s'appuie, les en-têtes qu'il concerne et une recommandation. Les contrôles réussis sont listés aussi, si bien qu'un résultat propre est visible et pas seulement vide. Deux règles que suivent les recommandations, car le conseil évident est souvent le mauvais : rien ici ne vous dit d'ouvrir une méthode, un en-tête ou une origine juste pour faire disparaître un encadré rouge - un DELETE bloqué peut être un point de terminaison correctement verrouillé - et rien ici ne suggère jamais de renvoyer en écho une origine arbitraire. La réponse est une liste d'autorisation, à chaque fois.
Ce qu'il ne prétend pas
CORS décide quelles origines peuvent lire une réponse à l'intérieur d'un navigateur. Ce n'est pas de l'authentification, cela n'accorde aucune permission, et cela n'arrête pas la falsification de requête inter-sites, car une attaque CSRF n'a jamais besoin de lire la réponse. Tout client qui n'est pas un navigateur l'ignore entièrement. Cet outil le dit explicitement, plutôt que de laisser un verdict vert suggérer que votre point de terminaison est protégé.