Ce que vérifie cet outil
Le Cross-Origin Resource Sharing (CORS) est le mécanisme qui détermine si du JavaScript exécuté sur autre-site.com est autorisé à lire une réponse de votre-site.com. Par défaut, les navigateurs bloquent cela — les en-têtes CORS servent à ce qu'un serveur l'autorise explicitement, et l'ampleur de cette autorisation compte. Cet outil envoie une seule requête avec un en-tête Origin synthétique et examine précisément ce que le serveur autorise en retour : une origine précise, un joker, ou — le cas risqué — un simple écho de n'importe quelle origine reçue.
Pourquoi la réflexion d'origine est le vrai danger
Un joker (Access-Control-Allow-Origin: *) paraît permissif, mais les navigateurs refusent d'attacher cookies ou authentification HTTP à une réponse en joker, donc cela ne peut rien exposer de ce à quoi un visiteur est connecté. La réflexion d'origine est différente : comme le serveur recopie exactement l'en-tête Origin reçu au lieu d'utiliser un * littéral, ce n'est pas un joker du point de vue du navigateur — ce qui signifie que cela peut être combiné avec Access-Control-Allow-Credentials: true. Cette combinaison permet à n'importe quel site de faire une requête authentifiée vers votre API au nom d'un visiteur connecté et de lire la réponse, ce qui équivaut fonctionnellement à une faille de type cross-site request forgery avec lecture de la réponse en prime.
Une façon courante d'y arriver par accident
Les équipes implémentent souvent CORS en récupérant l'en-tête Origin entrant et en le renvoyant tel quel — parfois pour supporter plusieurs domaines front-end (préproduction, production, site vitrine) sans maintenir une liste à la main. Cela fonctionne pour tous ces domaines, et pour n'importe quel autre aussi, puisque rien n'a jamais été réellement vérifié. Le correctif est presque toujours le même : remplacer l'écho par une vraie comparaison contre une liste autorisée.