Erreurs CORS après le déploiement : causes réelles et correctifs

Pourquoi CORS peut soudainement casser après le déploiement

CORS est une règle du navigateur, pas du serveur. Votre JavaScript frontend s'exécute dans un onglet de navigateur, et c'est le navigateur qui décide s'il peut lire une réponse provenant d'une origine différente (domaine, protocole ou port). Si votre backend ne renvoie pas les bons en-têtes CORS, le navigateur bloque la réponse même si le serveur a effectivement envoyé des données.

C'est pour cela que les erreurs CORS après déploiement sont déroutantes : rien n'a « changé » dans votre code, mais l'origine a changé. En local vous appelez peut-être http://localhost:5173 vers http://localhost:3000. Après le déploiement, cela devient quelque chose comme https://app.yourdomain.com appelant https://api.yourdomain.com. Différents domaines, HTTPS, et parfois des ports différents signifient une origine différente, donc le navigateur re-vérifie les permissions.

Les symptômes courants ressemblent souvent à l'un de ces cas :

• « Blocked by CORS policy » même si l'API fonctionne dans Postman ou curl
• Une requête de préflight (OPTIONS) échoue avant que la vraie requête ne s'exécute
• Les en-têtes CORS sont absents sur les erreurs (401/403/500), donc ça ne plante que lorsqu'il y a un problème
• Les requêtes avec cookies cessent soudainement de fonctionner

Le déploiement ajoute aussi des éléments invisibles. Un reverse proxy, un CDN ou une configuration de plateforme peut remplacer des en-têtes, les supprimer ou mettre en cache une mauvaise version. Le passage à HTTPS peut changer le comportement des cookies (SameSite et Secure), ce qui affecte ensuite les requêtes « credentials ».

Un exemple réaliste : votre frontend commence à envoyer fetch(..., { credentials: 'include' }) en production pour garder les utilisateurs connectés. Si le backend répond avec Access-Control-Allow-Origin: *, le navigateur le rejette car les origines génériques ne peuvent pas être utilisées avec des credentials.

Si vous avez hérité d'une configuration frontend-backend générée par une IA, ces incompatibilités sont courantes. Chez FixMyMess, le gain le plus rapide consiste souvent à vérifier l'origine déployée, puis à s'assurer que chaque chemin de réponse (y compris les erreurs) renvoie des en-têtes CORS cohérents.

Preflight 101 : la requête OPTIONS que vous n'avez pas remarquée

Beaucoup d'erreurs CORS après déploiement ne concernent pas du tout votre appel API réel. Le navigateur envoie souvent d'abord une petite requête de « preflight ». C'est une requête OPTIONS qui demande au serveur : « Si j'envoie cette vraie requête depuis cette origine, allez-vous l'autoriser ? »

Requêtes simples vs préflight

Certaines requêtes sont « simples » et évitent le préflight. Beaucoup d'appels frontend modernes ne sont pas simples, donc le navigateur les préflight.

Le préflight est déclenché par des éléments tels que :

• Des méthodes autres que GET/POST/HEAD (par exemple PUT, PATCH, DELETE)
• L'envoi de JSON avec Content-Type: application/json
• Tout en-tête personnalisé (comme Authorization, X-Requested-With ou X-Api-Key)
• L'utilisation d'options fetch qui ajoutent des en-têtes inattendus

Cela signifie que vous pouvez frapper votre endpoint directement et voir « 200 OK », pourtant le navigateur bloque l'appel. Pourquoi ? Parce que le navigateur ne passe jamais l'étape OPTIONS. Si OPTIONS retourne 404, 401, 500, ou manque les en-têtes CORS, la vraie requête n'est jamais envoyée.

Pourquoi les redirections cassent souvent le preflight

Un échec courant uniquement en production est une redirection inattendue sur OPTIONS. Par exemple, votre API peut rediriger HTTP vers HTTPS, ajouter ou supprimer « www », ou envoyer les requêtes non authentifiées vers une route de connexion. Les navigateurs gèrent mal les redirections sur le preflight, et beaucoup les traitent comme un échec même si l'URL redirigée fonctionnerait.

Un exemple pratique : votre frontend sur https://app.example.com appelle https://api.example.com. L'API est correcte, mais OPTIONS vers /v1/data renvoie un 301 vers /v1/data/ (slash final). Votre GET peut toujours réussir dans les tests, mais le navigateur bloque parce que le preflight n'a pas obtenu une réponse CORS propre.

La correction consiste généralement à : faire en sorte que OPTIONS renvoie directement un succès (souvent 204 ou 200), inclue les mêmes en-têtes CORS que les réponses réelles, et ne redirige jamais.

Origins : ce qui doit correspondre, et ce que l'on confond souvent

Beaucoup d'erreurs CORS après déploiement surviennent parce que l'origine autorisée que vous avez configurée n'est pas la même chaîne que celle envoyée par le navigateur.

La chose clé que l'on confond est Origin vs Host. Votre serveur reçoit un en-tête Host (où la requête est adressée) et le navigateur envoie un en-tête Origin (où la page qui fait la requête est hébergée). Les décisions CORS se basent sur Origin, pas sur Host.

Une origine n'est pas seulement un domaine. C'est un trio exact : schéma + domaine + port.

Correspondance exacte d'origine (schéma, domaine, port)

Si votre frontend s'exécute à https://app.example.com et votre API est https://api.example.com, le navigateur enverra Origin: https://app.example.com. Votre backend doit répondre avec Access-Control-Allow-Origin: https://app.example.com (ou une allowlist côté serveur qui renvoie cette valeur exacte).

http vs https est le piège classique au déploiement. En local, vous testez peut‑être depuis http://localhost:3000. Après le déploiement, le site devient https://... et votre allowlist inclut encore la version http, donc le navigateur bloque.

Incompatibilités courantes à rechercher

Vérifiez ces petites différences qui cassent CORS :

• https://example.com vs https://www.example.com
• Un port manquant : https://example.com vs https://example.com:8443
• Domaines de staging : https://staging.example.com vs https://app.example.com
• Origines locales inattendues : http://127.0.0.1:3000 vs http://localhost:3000
• Builds mobiles ou previews qui utilisent un domaine différent de la production

Un scénario réel rapide : votre frontend est servi depuis https://www.brand.com, mais vous n'avez autorisé que https://brand.com. Tout semble identique pour un humain, mais pour le navigateur c'est une origine différente.

Si vous avez hérité d'un backend généré par une IA, il a souvent une liste d'origines codée en dur qui n'a jamais été mise à jour pour le domaine live. FixMyMess commence typiquement par lire les valeurs Origin en production puis aligne l'allowlist sur ces chaînes exactes.

En-têtes de réponse CORS qui doivent être corrects à chaque fois

CORS n'est pas un réglage ponctuel. Le navigateur vérifie des en-têtes de réponse spécifiques sur chaque requête cross-origin, et il est strict à leur sujet. Si un en-tête manque sur une seule route (souvent la route OPTIONS), vous pouvez obtenir des erreurs CORS qui semblent aléatoires.

Le navigateur veut surtout savoir : mon Origin est‑il autorisé, et pour ce type de requête, la méthode et les en-têtes sont‑ils autorisés ? Cela signifie que votre API doit renvoyer Access-Control-Allow-Origin qui correspond à l'origine appelante (par exemple https://app.example.com). Si vous renvoyez la mauvaise origine, ou l'oubliez sur certains endpoints, le navigateur bloque la réponse même si le serveur renvoie 200.

Les échecs de préflight viennent souvent de Access-Control-Allow-Headers. La requête preflight inclut Access-Control-Request-Headers avec ce que le navigateur prévoit d'envoyer. Si votre réponse n'inclut pas chacun de ces en-têtes (manques fréquents : Authorization, Content-Type, X-Requested-With), le navigateur stoppe avant la vraie requête.

Le cache peut aussi rendre CORS incohérent. Si vous autorisez plusieurs origines, ajoutez Vary: Origin pour que les CDN et proxies ne mettent pas en cache la réponse CORS d'une origine et la servent ensuite à une autre.

Pour le preflight OPTIONS, retourner 204 No Content est acceptable, mais les en-têtes doivent toujours être présents. Une réponse preflight propre contient généralement :

• Access-Control-Allow-Origin
• Access-Control-Allow-Methods (inclure la méthode utilisée, comme GET, POST, PATCH)
• Access-Control-Allow-Headers (couvrir ce que le navigateur a demandé)
• Vary: Origin
• Optionnel : Access-Control-Max-Age pour réduire les préflights répétés

Un conseil pratique : assurez-vous que votre middleware CORS s'exécute avant le routage, les vérifications d'auth et les gestionnaires d'erreur. Sinon, les réponses 401/403/500 peuvent passer sans en-têtes CORS et déclencher des messages « CORS bloqué » qui ne sont en réalité que des erreurs d'auth ou du serveur.

Credentials et jokers : le piège le plus courant en production

Beaucoup d'erreurs CORS après déploiement proviennent d'une règle que l'on n'apprend qu'en production : on ne peut pas combiner credentials et origine générique (*).

Si le navigateur envoie des cookies (ou si vous lui dites d'envoyer des credentials), le serveur doit répondre avec une origine spécifique, pas *. Donc ceci échouera :

• Access-Control-Allow-Origin: *
• Access-Control-Allow-Credentials: true

Cookies vs Authorization : pourquoi ils se comportent différemment

Les cookies sont attachés automatiquement par le navigateur, d'où un contrôle strict. Si votre frontend et votre API sont sur des domaines différents, les cookies ne seront pas envoyés à moins que vous ne l'activiez explicitement côté frontend et que le backend l'autorise.

Un en-tête Authorization: Bearer ... est différent. Il ne dépend pas des cookies, mais il déclenche souvent un préflight car ce n'est pas une requête simple. Cela peut aussi casser, mais le piège « wildcard + credentials » concerne généralement les cookies.

Côté frontend, cette ligne change toute la règle :

fetch("https://api.example.com/me", {
  credentials: "include"
})

Dès que vous ajoutez credentials: "include" (ou withCredentials: true dans Axios), le navigateur rejette les réponses à moins que le backend soit très explicite.

Ce que le backend doit renvoyer (à chaque fois)

Assurez-vous que vos réponses API incluent :

• Access-Control-Allow-Origin: https://your-frontend.com (correspondance exacte)
• Access-Control-Allow-Credentials: true
• Vary: Origin (pour que les caches ne mélangent pas les origines)

Scénario d'exemple : en local vous appelez http://localhost:3000 vers http://localhost:8000 et tout fonctionne. En production vous passez à https://app.yourdomain.com et commencez à utiliser des cookies pour la connexion. Si votre serveur répond encore Access-Control-Allow-Origin: *, le navigateur bloque la réponse même si l'API renvoie 200.

Si vous avez hérité d'un code backend généré par une IA, cette mauvaise configuration est fréquente. FixMyMess trouve souvent les bons en-têtes sur une route, mais absents sur les rafraîchissements d'auth ou les réponses d'erreur, ce qui rend le bug aléatoire.

Proxies, CDN et configuration de plateforme qui modifient votre app

Les erreurs CORS après déploiement apparaissent souvent parce que votre frontend ne parle plus directement à votre serveur d'application. Un reverse proxy, un load balancer, un CDN ou une couche « sécurité » de la plateforme peut modifier les requêtes et réponses d'une manière que votre setup local n'a jamais connue.

Quand l'edge change vos en-têtes

Beaucoup de proxies peuvent ajouter, supprimer ou dupliquer des en-têtes. Si votre app renvoie le bon Access-Control-Allow-Origin, mais que le proxy l'écrase (ou en ajoute un deuxième), les navigateurs peuvent rejeter la réponse. Autre problème discret : le proxy compresse ou redirige différemment, et la réponse de redirection manque d'en-têtes CORS même si le point final final est correct.

Une défaillance fréquente uniquement en production est que les requêtes OPTIONS n'atteignent jamais votre app. Certaines plateformes traitent OPTIONS comme suspect, le bloquent avec une règle de firewall, ou le routent vers un handler par défaut qui renvoie 404/405 sans en-têtes CORS. Du côté navigateur, on voit « CORS est cassé », mais le vrai problème est le routage.

Le cache CDN peut servir les mauvais en-têtes CORS

Si un CDN met en cache des réponses d'API sans varier par Origin, il peut accidentellement servir une réponse dont les en-têtes CORS sont destinés à un autre site. Exemple : l'utilisateur A frappe votre API depuis https://app.example.com et le CDN met en cache la réponse avec cette origine autorisée. L'utilisateur B frappe la même URL depuis https://admin.example.com et reçoit les en-têtes en cache, qui ne correspondent pas, donc le navigateur bloque.

Voici ce qu'il faut vérifier, dans l'ordre :

• Vérifiez les en-têtes de réponse à l'edge (CDN/proxy) et côté serveur app, et confirmez qu'ils correspondent.
• Confirmez que les requêtes OPTIONS sont autorisées et routées vers votre app, pas bloquées ou traitées par une règle par défaut.
• Assurez-vous que les redirections (http → https, apex → www) renvoient aussi des en-têtes CORS.
• Si un cache est impliqué, assurez-vous que les réponses varient par Origin ou désactivez le cache pour les routes API.
• Comparez ligne par ligne les règles proxy de staging vs production.

Si vous avez hérité d'un backend généré par une IA, ce décalage de couche proxy est une cause fréquente que FixMyMess identifie lors d'un audit, car l'app « a l'air correcte » mais la config edge est silencieusement discordante.

Variables d'environnement et allowlists de domaines : points de rupture silencieux

Les erreurs CORS après déploiement proviennent souvent d'un changement banal : votre frontend appelle désormais une URL différente de celle que vous croyez. En local, un serveur dev peut proxyser les requêtes et masquer le problème. En production, le navigateur parle directement à l'API, donc tout écart apparaît immédiatement.

Un échec courant est de livrer le frontend avec la mauvaise URL de base d'API. Par exemple, votre build récupère API_URL=https://staging-api... (ou une vieille URL de preview) parce que la variable d'environnement de production n'a jamais été définie, ou que la plateforme a mis en cache un build précédent. Le navigateur envoie alors des requêtes depuis votre domaine live vers une API de staging qui n'autorise pas cette origine.

Un autre point de rupture est l'allowlist côté backend. Les équipes ajoutent http://localhost:3000 en dev et oublient d'ajouter le vrai domaine plus tard. Ça empire quand vous avez plusieurs domaines : www vs non-www, un domaine marketing, un sous-domaine app, et un domaine de preview. Si même une origine manque, cet environnement va échouer « aléatoirement ».

Pour éviter la dérive, centralisez vos origines autorisées et considérez-les comme une surface de configuration réelle, pas des chaînes éparpillées.

Une façon pratique d'éviter la dérive de config

Gardez les règles en un seul endroit et restez strict :

• Utilisez une variable d'environnement unique pour les origines autorisées (séparées par des virgules), parsée au démarrage.
• Normalisez les domaines (incluez le schéma et l'hôte exact que vous servez : https://app.example.com).
• Maintenez des valeurs séparées pour dev, staging et production, et documentez quelle URL frontend correspond à quelle API.
• Journalisez l'allowlist résolue au démarrage (et l'Origin des requêtes lors des échecs CORS).
• Ajoutez un petit test de fumée après chaque déploiement : un appel API depuis le domaine réel.

Si vous avez hérité d'une app générée par IA, c'est un diagnostic fréquent chez FixMyMess : le frontend pointe vers un environnement tandis que la config CORS backend pointe vers un autre, et personne ne s'en aperçoit avant le premier déploiement réel.

Une stratégie reproductible pour corriger CORS (étape par étape)

Quand des erreurs CORS après déploiement apparaissent, traitez-les comme une tâche de débogage, pas comme un jeu de devinettes. L'objectif est de trouver la requête exacte que le navigateur bloque et l'en-tête exact qui manque ou est mal apparié.

Commencez par l'onglet Réseau des DevTools du navigateur. Filtrez par l'appel API en échec, puis cherchez une requête OPTIONS juste avant. Si vous voyez OPTIONS, vous êtes face à un préflight. Si vous n'en voyez pas, l'erreur concerne généralement la vraie requête (souvent un en-tête manquant sur une réponse 401/500).

Suivez cette séquence et ne sautez aucune étape :

1. Reproduire et capturer la requête en échec : copiez les détails de la requête depuis l'onglet Réseau, y compris la méthode, l'URL, le code de statut et si un preflight OPTIONS a eu lieu.
2. Confirmer l'Origin exact : lisez l'en-tête Origin de la requête et notez‑le exactement (schéma + domaine + port). Beaucoup de problèmes « ça correspond » sont en réalité http vs https ou www vs non-www.
3. Vérifier les en-têtes sur les deux réponses : ouvrez la réponse OPTIONS et la réponse de la requête réelle. Les deux doivent inclure les bons en-têtes CORS (surtout Access-Control-Allow-Origin, et pour les cookies : Access-Control-Allow-Credentials).
4. Éliminer redirections et surprises middleware : si l'API redirige (301/302) ou force un slash, le preflight échoue souvent car la réponse redirigée n'inclut pas les en-têtes CORS. Faites en sorte qu'OPTIONS renvoie 200/204 directement avec les en-têtes.
5. Passez de « * » à une allowlist explicite : définissez une liste courte d'origines autorisées pour la production, retestez, puis ajoutez uniquement ce dont vous avez réellement besoin.

Un contrôle de sanity rapide : si vous utilisez des cookies ou des en-têtes d'auth, vous ne pouvez pas utiliser Access-Control-Allow-Origin: *. Vous devez renvoyer explicitement l'origine autorisée et activer les credentials.

Si votre backend a été généré par un outil IA et que la logique CORS est dispersée sur plusieurs routes, proxies et paramètres de plateforme, FixMyMess peut identifier la source unique de vérité et la corriger après un audit de code gratuit.

Erreurs fréquentes qui maintiennent CORS cassé

Beaucoup d'erreurs CORS après déploiement sont auto-infligées. En local tout semble bien car vous êtes sur une seule origine, vous faites des requêtes simples, et votre serveur dev est permissif. La production est plus stricte : domaines différents, HTTPS, cookies, et parfois un proxy ou CDN devant.

Voici les erreurs qui reviennent le plus quand un frontend parle à un backend séparé :

• Autoriser n'importe quelle origine en développement, puis activer les cookies ou l'auth en production sans changer CORS (on ne peut pas utiliser * avec des credentials).
• Ajouter les en-têtes CORS seulement sur le chemin heureux, mais pas sur les réponses 401/403/500, de sorte que le navigateur masque l'erreur réelle derrière un message CORS.
• Oublier que le navigateur envoie un preflight OPTIONS pour beaucoup de requêtes, et que votre serveur/router/middleware n'y répond pas avec les mêmes en-têtes CORS.
• Faire confiance aux valeurs par défaut du framework (ou coller un snippet CORS trouvé) sans vérifier les en-têtes réels en production.
• Tenter de le résoudre côté frontend en changeant les options fetch/axios, alors que CORS est appliqué par le navigateur et doit être corrigé côté serveur.

Un piège facile à manquer : vous ajoutez Access-Control-Allow-Origin pour votre GET /api/me, mais votre couche d'auth bloque la requête en amont. La réponse 401 n'inclut pas d'en-têtes CORS, donc le navigateur rapporte une erreur CORS au lieu d'« unauthorized ». On croit que CORS est cassé, alors que le vrai problème est l'absence d'en-têtes CORS sur les erreurs.

Un autre piège courant est de mélanger credentials et wildcard. Si votre frontend utilise des cookies (ou Authorization) et que vous mettez withCredentials: true, le backend doit renvoyer une origine spécifique (par exemple https://app.example.com) et autoriser les credentials. Retourner * échouera.

Si vous avez hérité d'un code généré par une IA, ces problèmes sont souvent disséminés entre middleware, fonctions serverless et reverse proxies. FixMyMess voit régulièrement des projets où CORS est « configuré » à un endroit mais écrasé ailleurs. La voie la plus rapide est de vérifier les réponses réelles en production pour OPTIONS et pour la requête finale, y compris les cas d'erreur.

Exemple : le frontend fonctionne en local, casse sur le domaine live

Une histoire commune : vous avez construit une app React sur http://localhost:3000 et une API sur http://localhost:8080. Vous vous connectez, l'API pose un cookie, et chaque requête fonctionne.

Puis vous déployez. L'app React passe à https://app.yourdomain.com, l'API devient https://api.yourdomain.com, et soudainement vous voyez des erreurs CORS après le déploiement. La partie déroutante est que le code n'a pas changé.

Ce qui a réellement changé, ce sont les règles du navigateur. Les cookies cross-site et les vérifications de préflight sont plus strictes sur de vraies origines HTTPS. En local, vous ne déclenchiez peut‑être pas le préflight, ou votre serveur dev proxyait silencieusement les requêtes de sorte que le navigateur ne voyait jamais un appel cross-origin.

Voici ce qui règle typiquement cette configuration :

• Mettre Access-Control-Allow-Origin à l'origine frontend exacte (https://app.yourdomain.com), pas *.
• Mettre Access-Control-Allow-Credentials: true sur le préflight (OPTIONS) et sur la réponse réelle.
• Assurer que le serveur répond à OPTIONS pour la même route avec 200/204 et les mêmes en-têtes CORS.
• Côté frontend, envoyer les cookies volontairement (pour fetch : credentials: "include"; pour Axios : withCredentials: true).
• S'assurer que les cookies sont compatibles avec les requêtes cross-site (souvent SameSite=None; Secure).

Comment confirmer la correction en production : ouvrez DevTools Réseau, trouvez la requête en échec et vérifiez deux entrées. D'abord, le preflight OPTIONS doit retourner un succès et inclure les en-têtes allow-origin et allow-credentials. Ensuite, la requête API réelle doit renvoyer les mêmes en-têtes et effectivement définir ou envoyer le cookie.

Si un backend généré par une IA est incohérent (OPTIONS géré par une couche, requête réelle par une autre), des plateformes comme FixMyMess identifient souvent rapidement le décalage lors d'un audit de code et le patchent en toute sécurité.

Checklist rapide et étapes suivantes

Quand vous voyez des erreurs CORS après le déploiement, considérez-le comme un problème d'appariement d'en-têtes, pas comme une énigme. Commencez par vérifier ce que le navigateur a réellement reçu sur la requête en échec et (si présent) sur le préflight.

Voici des vérifications rapides qui attrapent la plupart des problèmes réels :

• Confirmez que l'Origin correspond exactement à ce que le serveur autorise (schéma + domaine + port). https://app.com et https://www.app.com sont des origines différentes.
• Si vous envoyez des cookies ou de l'auth, assurez-vous que les règles de credentials sont correctes : la réponse doit inclure Access-Control-Allow-Credentials: true et l'origine ne peut pas être *.
• Ouvrez le panneau réseau et inspectez le preflight OPTIONS : il doit retourner un statut de succès (typiquement 200 ou 204), avec les mêmes en-têtes CORS que la requête réelle.
• Vérifiez que Access-Control-Allow-Headers inclut ce que vous envoyez réellement (manques fréquents : Authorization, Content-Type, X-Requested-With).
• Assurez-vous que le preflight n'est pas redirigé (301/302). Les redirections surviennent souvent après le déploiement à cause de HTTP → HTTPS, ou d'un slash manquant.

Si tout cela semble correct mais que ça échoue toujours, le problème est souvent une couche au-dessus de votre code : un proxy, CDN ou une config de plateforme qui réécrit les en-têtes, met en cache une ancienne réponse, ou répond différemment aux OPTIONS.

Étapes suivantes pour éviter le retour du problème :

• Notez les origines autorisées par environnement (local, staging, production) et stockez-les en config centralisée, pas dispersées.
• Ajoutez un simple test d'intégration qui interroge le domaine déployé et vérifie les en-têtes de preflight.
• Choisissez une approche d'auth (cookies ou tokens) et alignez CORS et les paramètres de session sur cette approche.
• Loggez les requêtes OPTIONS en production, au moins temporairement, pour voir statuts et en-têtes.

Si votre app a été générée par des outils comme Lovable, Bolt, v0, Cursor ou Replit et que la configuration CORS est enchevêtrée entre le code backend et les paramètres de déploiement, FixMyMess peut réaliser un audit de code gratuit et faire fonctionner ensemble les en-têtes backend et la configuration de plateforme rapidement.