Testeur CORS

Suivant

Les erreurs CORS sont le rouge “classique” de la console du navigateur : vous accédez à une API d’une origine différente et le navigateur bloque la réponse. Ce testeur envoie une requête OPTIONS préalable vers n’importe quelle URL que vous collez, avec l’origine et la méthode de votre choix, puis décode les en-têtes Access-Control-* afin que vous puissiez voir exactement ce que le serveur autorise, ce qu’il bloque et pourquoi le navigateur se plaint.

Comment tester CORS

  1. 1

    Entrez l'URL cible

    Le point de terminaison API que vous souhaitez appeler depuis votre front-end. Incluez la chaîne de requête et le protocole.

  2. 2

    Définissez la méthode et l'origine

    GET/POST/PUT/DELETE/PATCH. L'origine peut être l'URL de votre site ou toute origine que vous souhaitez simuler.

  3. 3

    Comprendre la requête préalable

    Le testeur envoie toujours une requête OPTIONS avec l'origine et la méthode choisies, plus l'en-tête Access-Control-Request-Headers: Content-Type, exactement la requête préalable qu'un navigateur envoie avant une requête JSON.

  4. 4

    Exécutez le test

    Le testeur envoie la requête préalable et rapporte le statut HTTP ainsi que les en-têtes de réponse CORS : Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials et Max-Age.

  5. 5

    Corrigez la mauvaise configuration

    Le rapport signale ce qui manque ou est incorrect, Allow-Origin manquant, en-tête interdit, méthode non autorisée.

Les en-têtes qui comptent

En-tête Ce qu’il fait
Access-Control-Allow-Origin Quelles origines peuvent lire la réponse
Access-Control-Allow-Methods Préliminaire : quelles méthodes sont autorisées
Access-Control-Allow-Headers Préliminaire : quels en-têtes de requête sont autorisés
Access-Control-Allow-Credentials Si les cookies/auth sont autorisés
Access-Control-Expose-Headers Quels en-têtes de réponse JS peut lire
Access-Control-Max-Age Combien de temps le résultat de la requête préalable est mis en cache

Requêtes simples vs. préalables

Une requête est “simple” (pas de préalable) uniquement si toutes ces conditions sont vraies :

  • La méthode est GET, HEAD ou POST.
  • Les en-têtes sont limités à Accept, Accept-Language, Content-Language, Content-Type (avec des valeurs spécifiques).
  • Content-Type, s’il est présent, est application/x-www-form-urlencoded, multipart/form-data ou text/plain.

Tout le reste, un corps JSON, un en-tête Authorization, un en-tête personnalisé X-Foo, un PUT/DELETE/PATCH, déclenche une requête préalable OPTIONS. Les serveurs doivent répondre à la requête préalable avec les bons en-têtes Allow-* ou la requête réelle ne s’exécute jamais.

Échecs CORS courants

  • “Pas d’en-tête Access-Control-Allow-Origin” → le serveur ne définit pas l’en-tête. Corrigez cela côté serveur, pas côté client.
  • “Le mode des identifiants nécessite que Allow-Origin ne soit pas *” → si vous envoyez des cookies, Allow-Origin doit être une origine spécifique (ou renvoyer l’en-tête Origin).
  • “En-tête de requête X non autorisé” → ajoutez X à Access-Control-Allow-Headers dans la réponse préalable.
  • “Méthode non autorisée” → ajoutez la méthode à Access-Control-Allow-Methods.
  • “Redirection non autorisée dans la requête préalable” → la requête préalable ne peut pas suivre les redirections. Le point de terminaison OPTIONS doit répondre directement.

Allow-Origin: * vs. renvoyer l’Origin

Access-Control-Allow-Origin: * est permissif mais ne peut pas être combiné avec des identifiants. En production, renvoyez l’Origin de la requête (après l’avoir validée à partir d’une liste d’autorisation) et définissez Allow-Credentials: true si vous avez besoin de cookies.

Proxy comme solution de contournement

Si vous ne pouvez pas contrôler le serveur, un proxy léger sur votre propre domaine supprime complètement CORS, le navigateur voit la même origine. De nombreuses plateformes d’hébergement (Vercel, Netlify, Cloudflare) offrent des règles de réécriture pour cela.

Questions fréquentes

Pour empêcher une page malveillante de lire des données privées sur un autre site en utilisant les cookies de votre navigateur. Sans CORS, visiter evil.com pourrait lui permettre de demander l’API interne de votre banque en votre nom. CORS oblige la banque à autoriser explicitement les lectures inter-origines.

Seulement en développement. Chromium a une option --disable-web-security, mais elle affecte tous les sites et est dangereuse. La bonne solution passe par des en-têtes côté serveur ou un proxy.

Postman n’est pas un navigateur, il ignore complètement CORS. CORS n’est appliqué que par les navigateurs pour les requêtes JavaScript. Un serveur qui fonctionne dans Postman n’est pas automatiquement correct pour CORS.

Les images et les balises <script> classiques se chargent inter-origine sans CORS, mais JS ne peut pas lire leur contenu. <img crossorigin> et fetch() appliquent CORS, c’est pourquoi les images dessinées sur le canvas deviennent “contaminées” sans cela.

Outils similaires