Comment corriger les erreurs CORS (et pourquoi elles surviennent)

Une erreur CORS signifie que votre page web a tenté de lire une réponse provenant d'une autre origine (un autre domaine, port ou protocole), et que ce serveur n'a pas envoyé les en-têtes indiquant que c'est autorisé. Les navigateurs bloquent la réponse pour protéger les utilisateurs. Vous la corrigez sur le serveur, en renvoyant un en-tête Access-Control-Allow-Origin pour l'origine de votre site et en gérant les requêtes preflight OPTIONS, ou vous l'évitez en envoyant la requête via votre propre backend, sur la même origine.

C'est l'une des erreurs les plus déroutantes du développement web, car la requête atteint souvent le serveur sans problème. Ce guide explique ce qui se passe et comment corriger chaque variante.

Ce qu'on entend par « origine »

Une origine est la combinaison du protocole, du domaine et du port :

Les navigateurs appliquent la politique de même origine : le JavaScript d'une page peut lire librement les réponses de sa propre origine, mais pas celles des autres. CORS (Cross-Origin Resource Sharing, partage des ressources entre origines) est le mécanisme par lequel un serveur donne son accord : « les réponses de ce serveur peuvent être lues par des pages provenant de ces origines ».

Deux conséquences surprennent souvent :

• La requête atteint souvent le serveur. CORS empêche généralement votre code de lire la réponse, pas le serveur de recevoir la requête. Un POST peut avoir été enregistré même si vous avez vu une erreur.
• Seuls les navigateurs appliquent CORS. curl, Postman et le code côté serveur l'ignorent totalement. C'est pourquoi « ça marche dans Postman » ne vous dit rien sur CORS.

Étape 1 : Lire l'erreur exacte

Ouvrez les outils de développement (clic droit → Inspecter), allez dans la Console et lisez le message complet. La formulation de Chrome indique le problème :

Ouvrez ensuite l'onglet Réseau, repérez la requête en échec (et toute requête OPTIONS qui la précède), et regardez son code de statut et ses en-têtes de réponse.

Vérifiez d'abord le code de statut. Beaucoup d'« erreurs CORS » sont en réalité une erreur serveur déguisée. Si le serveur plante ou renvoie une 404, sa réponse d'erreur n'a souvent pas d'en-têtes CORS, donc le navigateur signale CORS au lieu du vrai problème. Corrigez la 500 ou la 404, et l'erreur CORS peut disparaître.

Étape 2 : Décider si vous devez appeler cette API depuis le navigateur

Avant d'ajouter des en-têtes, posez-vous la question : le navigateur doit-il appeler directement cette API ?

• Une API tierce qui nécessite une clé secrète (OpenAI, clé secrète Stripe, la plupart des services d'e-mail) ne doit jamais être appelée depuis le navigateur. La clé serait visible par chaque visiteur. Appelez-la depuis votre backend : le problème CORS disparaît, car les requêtes serveur à serveur ne sont pas soumises à CORS. Voir comment protéger vos clés d'API.
• Une API tierce que vous ne contrôlez pas et qui n'envoie pas d'en-têtes CORS ne peut pas être corrigée de votre côté. Appelez-la depuis votre backend.
• Votre propre API peut être corrigée en la configurant correctement. Voir la suite.

Étape 3 : Corriger sur votre serveur

Le serveur doit ajouter les bons en-têtes à ses réponses, y compris les réponses d'erreur.

Pour la requête réelle, envoyez :

• Access-Control-Allow-Origin: https://monapp.com (l'origine exacte de votre frontend, sans barre oblique finale)
• Vary: Origin, si la valeur dépend de l'origine qui a fait la demande

Pour la requête OPTIONS de preflight, répondez avec un statut de succès (200 ou 204) et :

• Access-Control-Allow-Origin: https://monapp.com
• Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE
• Access-Control-Allow-Headers: Content-Type, Authorization (chaque en-tête personnalisé que vous envoyez)
• Facultatif : Access-Control-Max-Age: 600, pour que le navigateur mette le preflight en cache un moment

La plupart des frameworks disposent d'un paquet ou d'un réglage qui fait cela. Dans Express, le paquet cors ; dans FastAPI, CORSMiddleware ; dans ASP.NET Core, AddCors ; dans Spring, @CrossOrigin ou une configuration CORS. Une configuration typique avec Express :

import cors from "cors";

app.use(cors({
  origin: ["https://monapp.com", "http://localhost:5173"],
  credentials: true,
}));

Placez la gestion de CORS avant vos routes et votre authentification, pour que les requêtes preflight (qui ne transportent pas de connexion) ne soient pas rejetées avec une 401.

Avec un générateur d'IA, décrivez précisément la configuration :

Le frontend sur https://monapp.com appelle l'API sur https://api.monapp.com et reçoit « Response to preflight request doesn't pass access control check ». Configure CORS sur l'API pour autoriser exactement https://monapp.com et l'origine de l'aperçu, autorise GET, POST, PATCH, DELETE avec les en-têtes Content-Type et Authorization, traite OPTIONS avant l'authentification, et inclus aussi les en-têtes CORS dans les réponses d'erreur.

Étape 4 : Gérer les cookies et les identifiants

Si votre frontend envoie des cookies (par exemple une session de connexion) à une autre origine, les deux côtés doivent être d'accord :

• Le frontend définit credentials: "include" sur fetch, ou withCredentials: true avec axios.
• Le serveur envoie Access-Control-Allow-Credentials: true.
• L'en-tête Access-Control-Allow-Origin du serveur doit être l'origine exacte, et non *.

Les cookies inter-sites nécessitent aussi SameSite=None; Secure sur le cookie, et certains navigateurs restreignent davantage les cookies tiers. C'est une raison de plus de privilégier l'approche de l'étape 5.

Étape 5 : Éviter CORS avec une configuration de même origine

Souvent, la solution la plus propre consiste à ne faire aucune requête inter-origines. Servez l'API depuis la même origine que la page, par exemple à https://monapp.com/api/... :

• En développement, la plupart des serveurs de développement peuvent faire office de proxy. L'option server.proxy de Vite peut transmettre /api à votre backend sur un autre port, de sorte que le navigateur ne communique qu'avec une seule origine.
• En production, routez /api vers le backend via les réglages de réécriture ou de proxy de votre hébergeur, ou servez le frontend et l'API depuis un même serveur.

Le frontend appelle alors un chemin relatif comme fetch("/api/orders"). Il n'y a plus de requête inter-origines, plus de preflight entre origines, et plus de problèmes de cookies. Vous n'avez pas non plus à coder en dur un domaine d'API qui diffère entre l'aperçu et la production.

Modifie le frontend pour appeler le backend avec des chemins relatifs /api au lieu d'une URL complète, et configure un proxy de développement pour que /api soit transmis au serveur d'API. Supprime ensuite les réglages CORS dont nous n'avons plus besoin.

Ce qu'il ne faut pas faire

• mode: "no-cors" dans fetch. Cela ne contourne rien ; cela donne à votre code une réponse vide et illisible.
• Les extensions de navigateur qui désactivent CORS. Elles ne modifient que votre navigateur. Chaque visiteur verra toujours l'erreur.
• Les services publics de « proxy CORS » pour de vraies applications. Ils peuvent lire et modifier tout ce qui passe par eux, et ils tombent en panne.
• Access-Control-Allow-Origin: * sur une API qui utilise des connexions. Cela ne fonctionne pas avec les identifiants de toute façon, et c'est le mauvais choix par défaut pour des données privées.
• Renvoyer en écho n'importe quelle en-tête Origin avec les identifiants autorisés. Cela permet à n'importe quel site web de faire des requêtes authentifiées au nom de vos utilisateurs. Utilisez une liste d'autorisation.

Causes fréquentes dans les applications créées avec l'IA

CORS dans Mythex

Lorsqu'un projet Mythex contient un site web et un serveur d'API, les deux tournent comme services dans le même projet, et vous pouvez basculer entre eux dans l'aperçu. Demander à l'agent que le frontend appelle le backend via un chemin /api relatif, transmis en développement, évite la plupart des problèmes CORS. Si vous avez vraiment besoin d'appels inter-origines, donnez à l'agent l'erreur exacte de la console et les origines concernées. Vérifiez aussi le résultat sur l'application publiée, car son adresse diffère de celle de l'aperçu. Voir Applications multi-services et Backends d'API dans la documentation, ainsi que nos guides sur le débogage d'une application créée avec l'IA et frontend vs backend.

Checklist CORS

• Lu le message complet de la console et le code de statut de la requête en échec
• Écarté une 404 ou une 500 cachée
• APIs à clé secrète appelées depuis le backend, et non depuis le navigateur
• Le serveur envoie Access-Control-Allow-Origin avec les origines autorisées exactes
• Le preflight OPTIONS reçoit les méthodes et en-têtes autorisés, avant l'authentification
• Les en-têtes CORS sont présents aussi dans les réponses d'erreur
• Identifiants : origine exacte, Allow-Credentials: true, réglages de cookies corrects
• Origines de l'aperçu, du site publié et du domaine personnalisé toutes couvertes, ou chemins /api relatifs utilisés
• Aucun raccourci no-cors, proxy public ou origine renvoyée en écho

Questions