Find out whether a browser would let your code read an API response, and exactly which check blocks it. Real preflight and request diagnostics, not a header dump.
Une origine par ligne, dix au maximum. Utile pour vérifier que le local, la préproduction et la production figurent tous sur la liste d'autorisation. Les résultats apparaissent sous forme de tableau dans l'onglet En-têtes.
Ces requêtes sont envoyées depuis les serveurs POLPROG vers le point de terminaison que vous indiquez, parce qu'un navigateur ne peut pas exécuter ce diagnostic sur lui-même : c'est justement CORS qui l'en empêcherait. Aucun de vos cookies n'est transmis, aucun corps de requête n'est jamais envoyé, les corps de réponse sont jetés, et rien n'est conservé une fois le rapport arrivé jusqu'à vous.
Une règle de navigateur, pas de serveur. Quand du JavaScript hébergé sur une origine demande une ressource sur une autre, le navigateur envoie la requête mais refuse de remettre la réponse à votre code, sauf si le serveur déclare, dans ses en-têtes de réponse, que l'origine qui fait la requête a le droit de la lire. Cross-Origin Resource Sharing est l'ensemble des en-têtes qui servent à le déclarer.
Si une requête fonctionne dans curl, Postman, Insomnia ou depuis votre propre backend, cela ne dit rien de la capacité du JavaScript d'un navigateur à la lire. Ces clients n'appliquent aucune règle CORS. Le serveur se comporte en général de façon identique dans les deux cas ; la différence tient entièrement à ce que l'appelant fait de la réponse.
Pour tout ce qui n'est pas une requête des plus simples, le navigateur envoie d'abord une requête OPTIONS pour demander si la requête réelle est autorisée. Elle porte Origin, Access-Control-Request-Method et, si nécessaire, Access-Control-Request-Headers. Si la réponse n'autorise pas la requête, la requête réelle n'est jamais envoyée : le point de terminaison ne la voit donc jamais et les journaux de votre serveur ne montrent rien.
Une requête n'est simple que si sa méthode est GET, HEAD ou POST et que chaque en-tête qu'elle définit figure sur la safelist CORS : Accept, Accept-Language, Content-Language, Content-Type et Range. La valeur compte aussi. Content-Type ne reste sur la safelist que pour application/x-www-form-urlencoded, multipart/form-data et text/plain.
Il ne fait pas partie des trois types de contenu de la safelist. C'est toute la raison. Un POST avec un corps JSON est une requête avec preflight, et c'est pourquoi ajouter une API JSON à une page existante produit soudain une requête OPTIONS que personne n'a écrite, ainsi que des erreurs venant d'une route qui ne gère que POST.
Soit une seule origine, soit *. Jamais une liste, jamais une valeur avec un chemin, jamais un joker à l'intérieur d'un nom d'hôte. La comparaison avec l'origine qui fait la requête est exacte : une barre oblique finale, un port par défaut écrit en toutes lettres, ou http là où la requête utilisait https feront tous échouer la comparaison tout en paraissant identiques à un humain.
Nécessaire quand la requête envoie des cookies ou une authentification HTTP. Sa seule valeur acceptée est la chaîne exacte true, en minuscules. Une requête avec identifiants ne peut pas non plus être satisfaite par Access-Control-Allow-Origin: *, et pour cette même requête un astérisque dans Allow-Methods, Allow-Headers ou Expose-Headers cesse d'être un joker et devient un nom littéral.
Si le serveur choisit la valeur d'Allow-Origin à partir de la requête entrante, la réponse dépend de l'en-tête Origin, et il faut le dire à tout cache partagé. Sans Vary: Origin, un CDN ou un proxy inverse peut stocker une réponse qui nomme une origine et la servir à une autre : des requêtes échouent alors pour des raisons qui n'apparaissent jamais dans l'application.
Une réponse cross-origin n'expose que sept en-têtes au script : Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified et Pragma. Tout le reste, y compris vos propres en-têtes X- et Location, se lit comme null tant qu'il n'est pas nommé dans Access-Control-Expose-Headers. Cet en-tête concerne la réponse et n'a rien à voir avec Allow-Headers, qui concerne la requête.
Il décide quelles origines peuvent lire une réponse dans un navigateur. Il ne décide pas qui a le droit d'appeler un point de terminaison, il n'accorde aucune permission, et il n'empêche pas la falsification de requête inter-sites : une attaque CSRF n'a pas besoin de lire la réponse, une politique CORS stricte la laisse donc intacte. Gardez l'authentification, l'autorisation et les tokens CSRF exactement tels qu'ils étaient.
Chaque verdict présenté ici provient d'un échange réel avec le point de terminaison que vous avez indiqué, évalué selon les règles du Fetch standard qu'applique un navigateur. Il décrit ce point de terminaison tel qu'il a répondu à l'infrastructure POLPROG à cet instant : un serveur dont la réponse varie selon le réseau, la région ou l'authentification peut répondre autrement à votre navigateur. Les temps sont observés depuis notre infrastructure et ne sont pas une mesure de navigateur. Le test de la requête réelle est désactivé par défaut pour les méthodes qui peuvent modifier des données, et aucun corps de requête n'est jamais envoyé.
Parce que CORS est appliqué par les navigateurs et par rien d'autre. Postman, curl, Insomnia et votre propre backend n'appliquent aucune règle CORS : ils reçoivent la réponse quels que soient les en-têtes qu'elle porte. Le serveur se comporte en général de façon identique dans les deux cas. La différence tient entièrement à ce que l'appelant fait de la réponse, et un navigateur refuse de la remettre à votre JavaScript tant que cette réponse ne dit pas que l'origine en question a le droit de la lire.
Une requête OPTIONS que le navigateur envoie avant la requête réelle, pour demander si celle-ci est autorisée. Elle porte Origin, Access-Control-Request-Method et, si nécessaire, Access-Control-Request-Headers. Si la réponse n'autorise pas la requête, la requête réelle n'est jamais envoyée : votre point de terminaison ne la voit donc jamais et les journaux de votre serveur ne montrent rien. Seules les requêtes qui ne sont pas simples passent par un preflight.
Content-Type ne figure sur la safelist CORS que pour application/x-www-form-urlencoded, multipart/form-data et text/plain. Ces trois-là, et rien d'autre. Un corps JSON place la requête hors de la safelist, le navigateur l'annonce donc à l'avance. C'est pourquoi ajouter une API JSON à une page existante produit soudain une requête OPTIONS que personne n'a écrite.
Parce qu'une réponse liée à un utilisateur connecté ne doit pas être lisible par tous les sites que cet utilisateur visite. Quand une requête envoie des cookies ou une authentification HTTP, le serveur doit nommer l'origine à laquelle il fait confiance, et un navigateur rejette le joker sans appel, même accompagné d'Access-Control-Allow-Credentials: true. Il en va de même pour un astérisque dans Allow-Methods, Allow-Headers et Expose-Headers : pour une requête avec identifiants, chacun est lu comme un nom d'en-tête littéral et non comme un joker.
Non. CORS décide quelles origines peuvent lire une réponse dans un navigateur. Ce n'est pas de l'authentification, il n'accorde aucune permission, et il n'empêche pas la falsification de requête inter-sites, parce qu'une attaque CSRF n'a pas besoin de lire la réponse. Tout client qui n'est pas un navigateur l'ignore complètement. Gardez votre authentification, vos vérifications d'autorisation et vos tokens CSRF exactement tels qu'ils sont.
Des serveurs POLPROG vers le point de terminaison que vous indiquez, parce qu'un navigateur ne peut pas exécuter ce diagnostic sur lui-même : c'est justement CORS qui l'en empêcherait. Seuls les en-têtes nécessaires à l'analyse sont envoyés, aucun de vos cookies n'est transmis, aucun corps de requête n'est jamais envoyé, et les corps de réponse sont jetés. Rien n'est conservé une fois le rapport arrivé jusqu'à vous, et les valeurs des en-têtes sensibles comme Authorization ne sont jamais affichées ni exportées.
Une entreprise demande souvent « un scanner de sécurité », mais le besoin réel comporte plusieurs couches :
Les en-têtes de sécurité HTTP permettent au serveur de définir les règles appliquées par le navigateur aux scripts, styles, frames, fonctions matérielles, données de référence, types MIME et connexions HTTPS. Une configuration adaptée réduit l’impact de certaines attaques XSS, du clickjacking, de la confusion MIME, des XS-Leaks et de l’intégration cross-origin non souhaitée.
Un bon audit de site web ne se résume ni à une note Lighthouse ni à une liste de dizaines d’avertissements automatiques. Il doit répondre à quatre questions : un moteur de recherche peut-il correctement découvrir et comprendre le site, l’utilisateur peut-il accomplir sa tâche efficacement, le site est-il suffisamment rapide et expose-t-il inutilement son propriétaire ou ses visiteurs à des risques ?
Nous développons des logiciels et des solutions sur mesure adaptés à vos besoins.