Réseau/HTTP
CORS Checker / Explainer
Expliquer étape par étape si le navigateur autorisera une requête cross-origin — classification simple/preflight, vérification des en-têtes Access-Control-* de la réponse, résumé.
Un par ligne, « Nom » ou « Nom : valeur » — la valeur n'affecte pas la classification.
Récupérez-les depuis l'onglet Network des DevTools (en-têtes de la réponse elle-même ou du preflight OPTIONS) ou avec curl -I.
CORS (Cross-Origin Resource Sharing) is a browser mechanism that decides whether JavaScript from one site is allowed to read a response from a server on a different domain. This tool walks through, step by step, whether a specific request will succeed and which Access-Control-* headers it needs.
How to use it
- Provide the method, the request's origin, and the server's response headers (Access-Control-Allow-Origin, etc.) and the tool determines whether the browser will let the request through.
- The "simple" vs. "preflight" classification shows whether the browser will first send an OPTIONS preflight request before the actual one.
- The summary gives the exact reason for a failure when a request would be blocked — faster than parsing the browser console's error message.
Common uses
- Debugging the classic "has been blocked by CORS policy" error with a step-by-step explanation of what's missing, instead of guessing.
- Checking a backend's CORS configuration before the frontend and API end up on separate domains in production.
- Understanding why a request with credentials: include is rejected even though Access-Control-Allow-Origin looks correct.
Things to keep in mind
CORS protects the user's browser, not the server — the restriction only applies to requests made from page JavaScript in a browser, not to requests from curl, Postman, or server-to-server calls.
Access-Control-Allow-Origin: * is incompatible with credentials: include — for requests carrying cookies or authorization, the server must return a specific origin instead of a wildcard.
Questions fréquentes
Pourquoi une requête échoue-t-elle avec une erreur CORS même si le serveur a répondu avec succès ?
CORS est appliqué par le navigateur, pas par le serveur — si la réponse manque d'un en-tête Access-Control-Allow-Origin correspondant à l'origine demandeuse, le navigateur empêche JavaScript de lire la réponse, même si la requête elle-même a abouti.
Quelle est la différence entre une requête simple et une requête avec préflight ?
Les requêtes simples (GET/POST basiques avec en-têtes standard) passent directement, tandis que les requêtes avec en-têtes personnalisés, d'autres méthodes ou certains types de contenu déclenchent d'abord une requête préflight OPTIONS pour vérifier la permission avant l'envoi de la requête réelle.
Vérifier les en-têtes CORS ici envoie-t-il mes données à un serveur ?
L'outil inspecte les en-têtes que vous fournissez ou récupère directement depuis votre navigateur — aucun serveur intermédiaire ne stocke les données de votre requête.
CORS protège-t-il une API contre les requêtes malveillantes ?
Non. CORS ne restreint que ce que le JavaScript dans le navigateur peut lire — un attaquant utilisant curl, Postman ou un script backend le contourne entièrement, donc l'authentification et l'autorisation réelles doivent être appliquées côté serveur.
Pourquoi Access-Control-Allow-Origin: * ne fonctionne-t-il pas avec credentials: include ?
La spécification interdit délibérément cette combinaison pour des raisons de sécurité : autoriser les credentials (cookies, en-têtes d'autorisation) avec un joker acceptant n'importe quelle origine serait une faille de sécurité grave, donc le serveur doit renvoyer une origine exacte lors de l'utilisation de credentials.