Le serveur simule la requête preflight et la requête réelle pour déterminer rapidement si le problème vient de Allow-Origin, Allow-Headers ou credentials.
Simule côté serveur les requêtes preflight CORS et les requêtes réelles, vérifie les 6 en-têtes de réponse un par un, localise avec précision les erreurs de configuration cross-origin et fournit du code de correction pour plusieurs frameworks comme Nginx/Node.js/Spring.
C'est le problème CORS le plus classique ! Parce que Postman et curl ne sont absolument pas soumis à la politique de même origine du navigateur — ce sont des clients HTTP, pas des navigateurs, ils n'interceptent pas les réponses, et n'envoient pas non plus automatiquement de requêtes preflight OPTIONS. Les erreurs cross-origin sont un mécanisme de sécurité exclusif au navigateur ; seul l'environnement d'exécution JavaScript du navigateur effectue des vérifications CORS. Que Postman puisse se connecter ne démontre que l'API elle-même peut retourner des données, ne démontre pas que la configuration CORS est correcte. Vous devez utiliser le navigateur, ou cet outil (qui simule le flux CORS du navigateur sur le serveur) pour vérifier, et là vous découvrirez le problème.
99% des erreurs CORS sont des problèmes de configuration du backend (ou des problèmes de configuration dans la couche Nginx/gateway), le frontend peut faire très peu. Le cœur de CORS est que le serveur « autorise » le navigateur via des en-têtes de réponse pour permettre l'accès cross-origin ; le frontend ne peut que configurer withCredentials, définir des en-têtes de requête, etc., il ne peut pas contourner les restrictions de sécurité du navigateur. Les proxys du frontend dont on parle sur internet (proxy devServer, proxy inverse Nginx qui proxifient frontend et API sur la même origine) essentiellement « trompent » le navigateur en lui faisant croire que c'est une requête de même origine, ils ne résolvent pas réellement le problème CORS ; en production si frontend et backend sont de différentes origines le backend doit encore configurer CORS correctement.
Parce que GET remplit normalement les conditions de requête simple, le navigateur envoie la requête directement ; tandis que POST si vous envoyez Content-Type: application/json (90% des APIs POST sont ça), n'appartient plus à une requête simple, déclenchera preflight OPTIONS. La requête preflight nécessite que le serveur retourne les en-têtes CORS corrects ; beaucoup de gens n'ont configuré les en-têtes CORS que pour GET/POST mais n'ont pas géré la méthode OPTIONS, ou la réponse OPTIONS n'a pas d'en-têtes, donc ça signale une erreur. Les méthodes PUT/DELETE/PATCH par elles-mêmes ne sont pas des méthodes simples, inévitablement elles déclenchent preflight.
En environnement de développement il y a plusieurs solutions : ① Proxy intégré au framework (devServer.proxy de Vue CLI, server.proxy de Vite, proxy de Create React App) : proxifie les requêtes d'API sur la même origine que le serveur de développement du frontend, le navigateur croit que c'est une requête de même origine sans cross-origin ; ② Désactiver les paramètres de sécurité du navigateur (par exemple Chrome avec le paramètre de démarrage --disable-web-security), seulement pour tests temporaires locaux, absolument pas pour la navigation normale ; ③ Configurer CORS sur le backend en autorisant l'origine localhost (recommandé, comportement cohérent avec la production). En production le backend doit configurer CORS correctement : configurer une liste blanche d'origines autorisées, définir correctement Allow-Methods/Allow-Headers/Allow-Credentials, ajouter Vary: Origin, ou utiliser gateway/Nginx pour gérer CORS de manière unifiée.
Non, l'en-tête de réponse Access-Control-Allow-Origin ne peut avoir qu'une seule valeur, soit une origine spécifique (comme https://a.com), soit *. Le navigateur n'accepte pas plusieurs origines (par exemple écrire https://a.com,https://b.com est invalide, le navigateur le considérera comme non correspondant). La bonne façon de configurer multi-origines est : le serveur maintient une liste blanche d'origines autorisées, à chaque fois qu'il reçoit une requête il lit la valeur d'Origin dans l'en-tête de requête, vérifie si cette Origin est dans la liste blanche, si oui définit Access-Control-Allow-Origin comme cette valeur d'Origin spécifique, et retourne en même temps l'en-tête Vary: Origin ; si non, ne retourne pas d'en-têtes CORS ou retourne une erreur. N'essayez pas de retourner plusieurs en-têtes Allow-Origin ou de séparer plusieurs valeurs par virgule, le navigateur ne les reconnaît pas.
La requête preflight OPTIONS n'a pas besoin de retourner aucune logique métier ni corps de réponse, elle n'a besoin que de retourner les en-têtes de réponse CORS corrects et le code de statut 200/204 est suffisant. Le navigateur en recevant les en-têtes CORS corrects considère que le preflight a réussi, il ne lira pas le contenu du body de la réponse OPTIONS. Donc la meilleure pratique est : intercepter directement les requêtes OPTIONS dans la couche Nginx/gateway, retourner 204 No Content et les en-têtes CORS corrects, sans renvoyer au serveur d'applications backend ; cela allège la charge du backend et évite également les erreurs 405 causées par des routes backend qui ne prennent pas en charge OPTIONS. Mais assurez-vous que les en-têtes CORS de la réponse OPTIONS sont cohérents avec les en-têtes CORS de la requête réelle.
Les requêtes cross-origin avec Cookie nécessitent de remplir simultanément trois conditions : ① XMLHttpRequest.withCredentials = true sur le frontend ou credentials: 'include' dans fetch ; ② En-tête de réponse backend Access-Control-Allow-Credentials: true ; ③ Access-Control-Allow-Origin ne peut pas être *, doit être une origine spécifique. Les trois conditions sont indispensables. De plus faites attention aux attributs de Cookie : le Cookie doit avoir défini SameSite=None; Secure (environnement HTTPS) pour pouvoir être emporté dans des requêtes cross-origin ; si le Cookie est SameSite=Lax ou Strict, dans des requêtes cross-origin il ne sera pas emporté ; l'attribut Domain du Cookie doit être configuré correctement ; faites également attention à l'impact des politiques de Cookie tierces (des navigateurs comme Chrome ont des restrictions sur les Cookies tiers).
CORS est un relâchement des restrictions d'accès cross-origin, CSRF est une attaque de falsification de requête intersite, ce sont des concepts différents. Configurer CORS correctement ne cause pas directement de vulnérabilités CSRF — parce que CORS ne permet qu'à JS de lire les réponses, tandis que CSRF c'est quand un attaquant induit l'utilisateur à envoyer des requêtes à son insu (comme des balises img, envoi automatique de formulaires), ces requêtes même sans CORS sont envoyées en emportant Cookie. Défendre CSRF nécessite d'utiliser CSRF Token, SameSite Cookie, vérifier Origin/Referer et d'autres solutions, on ne peut pas défendre CSRF en désactivant CORS. Mais si lors de la configuration CORS vous définissez Allow-Origin comme * et autorisez les identifiants, ça amplifiera effectivement le risque CSRF, c'est pourquoi dans des scénarios avec identifiants on ne peut absolument pas utiliser *, vous devez restreindre strictement la liste blanche d'origines.
Le chargement de ressources cross-origin avec des balises <img>, <script>, <link> normales (images CDN, scripts JS, CSS) par défaut n'a pas de problèmes CORS ; ce sont des « ressources incorporées » pas des « requêtes AJAX », le navigateur permet de les charger mais JS ne peut pas en lire le contenu. Mais si vous voulez manipuler des images cross-origin dans Canvas, ou charger ces ressources avec fetch/XHR et en lire le contenu, alors vous avez besoin de CORS, et en même temps vous devez ajouter l'attribut crossorigin sur la balise. Le téléchargement de fichiers cross-origin (clic sur balise a pour télécharger) par défaut ne nécessite pas non plus CORS. Les redirections affectent CORS : si la requête preflight OPTIONS retourne une redirection 3xx, le navigateur la rejettera directement (Preflight redirect is not allowed) ; si la redirection de la requête réelle est entre différentes origines, chaque saut doit retourner correctement les en-têtes CORS.
Points clés de configuration recommandée dans Nginx : ① Utiliser la directive map pour correspondre à la liste blanche d'Origins, en définissant dynamiquement la variable $cors_origin ; ② Les requêtes OPTIONS retournent directement 204 sans renvoyer au backend ; ③ add_header rappelez-vous d'ajouter le paramètre always pour vous assurer que les réponses d'erreur comportent également l'en-tête ; ④ Ajouter Vary: Origin ; ⑤ Configurer correctement Allow-Methods/Allow-Headers/Credentials. Vous pouvez trouver des configurations d'exemple dans les recommandations de correction des résultats de détection de cet outil ; nous fournissons des fragments de configuration vérifiés pour les frameworks principaux comme Nginx, Apache, Node.js Express, Spring Boot, Python Flask/Django, Koa, Go Gin.
Étapes pour vérifier CORS : ① D'abord utilisez la détection en ligne de cet outil, entrez URL, Origin, méthode, en-têtes, option d'identifiants, regardez si chaque vérification du preflight et de la requête réelle passe ; ② Ouvrez le panneau Network de DevTools du navigateur, cochez Disable cache pour désactiver le cache (en évitant l'interférence d'ancien cache), déclenchez la requête cross-origin, vérifiez que les en-têtes de réponse du preflight OPTIONS et de la requête réelle sont corrects ; ③ Dans Console regardez s'il y a des erreurs liées à CORS ; ④ Testez différents scénarios : requêtes GET sans en-têtes personnalisés, requêtes POST avec application/json, méthodes PUT/DELETE, avec Cookie/sans Cookie, avec en-têtes personnalisés ; ⑤ Simulez une requête OPTIONS avec curl : curl -i -X OPTIONS -H "Origin: https://yoursource.com" https://api.example.com/endpoint, vérifiez que les en-têtes de réponse sont corrects.
Différents navigateurs ont des différences dans les détails d'implémentation de la spécification CORS : ① Safari a des restrictions plus strictes sur Max-Age du cache preflight (anciennes versions seulement 600 secondes), la politique de Cookies (ITP anti-pistage intelligent) est également plus stricte, peut causer des problèmes de Cookie cross-origin ; ② Chrome a des vérifications plus strictes sur les jokers avec identifiants, Allow-Headers/Allow-Methods n'autorisent pas non plus *, certaines versions de Firefox peuvent être plus laxistes ; ③ L'ancien IE (IE11) utilise XDomainRequest au lieu de XMLHttpRequest standard, l'implémentation CORS a beaucoup de pièges (par exemple ne prend pas en charge les en-têtes personnalisés, ne prend en charge que GET/POST) ; ④ Différents navigateurs ont des différences subtiles dans la gestion de l'en-tête Vary, la gestion des redirections, la gestion des en-têtes de sécurité. La solution est de configurer strictement selon la spécification CORS, ne pas dépendre du comportement compatible d'un navigateur spécifique.
Il est recommandé de définir entre 3600 (1 heure) et 86400 (24 heures). Définir trop court (comme 60 secondes) : le cache preflight expire rapidement, envoyant fréquemment des requêtes OPTIONS, augmentant le temps de requête et la pression du serveur, l'impact est notable dans des environnements de réseau mobile faible. Définir trop long (comme 31536000, c'est-à-dire un an) : si vous mettez à jour la configuration CORS (par exemple en ajoutant des méthodes autorisées, en-têtes), l'ancien résultat preflight en cache dans le navigateur de l'utilisateur peut prendre beaucoup de temps à expirer, pendant cette période apparaîtront des problèmes de configuration qui ne prend pas effet. De plus Chrome et Firefox tronqueront automatiquement les valeurs qui dépassent 86400 secondes à 86400 secondes, peu importe comment vous le définissez ça ne sert à rien. En environnement de développement vous pouvez définir -1 pour désactiver le cache preflight, facilitant le débogage.
WebSocket (ws:// et wss://) ne sont pas soumis au mécanisme CORS HTTP, parce que WebSocket est un protocole indépendant, ce ne sont pas des requêtes HTTP AJAX. Mais la phase de handshake de WebSocket est une requête HTTP ; le serveur peut vérifier l'en-tête Origin pour décider s'il autorise la connexion — c'est un contrôle de permissions au niveau WebSocket, pas du CORS standard, mais le principe est similaire. Si la connexion WebSocket est rejetée, vous devez vérifier la configuration de vérification Origin du serveur WebSocket, pas les en-têtes CORS HTTP. Des bibliothèques comme Socket.IO peuvent avoir leur propre façon de configurer le cross-origin, similaire à la configuration CORS standard mais pas exactement identique. De plus, d'autres APIs du navigateur comme HTTP/2 Server Push, WebRTC ont également leur propre contrôle de permissions, ne suivent pas complètement le CORS HTTP.
Cet outil sur le serveur simule strictement selon la spécification W3C CORS le flux de preflight et de requête réelle du navigateur, la logique de vérification des en-têtes CORS est fondamentalement cohérente avec les navigateurs modernes. Si l'outil détecte que ça passe mais le navigateur signale toujours une erreur, les causes possibles sont : ① Le navigateur a mis en cache des résultats preflight ou d'anciennes réponses, faites un rechargement forcé Ctrl+F5 ou effacez le cache et réessayez ; ② Des extensions du navigateur (blocage de publicité, protection de la vie privée, plugins de sécurité) ont modifié ou intercepté la requête ; ③ L'Origin, les en-têtes de requête, la méthode, l'option d'identifiants que vous avez écrits dans l'outil ne sont pas cohérents avec ce que le frontend envoie réellement (par exemple le frontend emporte réellement un en-tête personnalisé que vous n'avez pas ajouté dans l'outil) ; ④ Cache incohérent sur les nœuds CDN/proxy, le nœud auquel l'outil demande et le nœud auquel le navigateur demande retournent des résultats différents ; ⑤ Le navigateur a des politiques de sécurité spéciales (comme les requêtes vers du contenu mixte HTTP dans des pages HTTPS sont bloquées, restrictions spéciales du protocole file:// de fichiers locaux).
