Anthony, Engineering Lead, vingt ans de code. Autodidacte : de l'usine au cybercafé, jusqu'aux systèmes que tu utilises tous les jours.


Anthony Capirchio


Ils sont là, tapis dans la console, prêts à te sauter au visage avec leurs grosses erreurs rouges dès que tu tentes un appel un peu ambitieux. Les fameux en-têtes CORS, ceux qui te rappellent que non, tout ne roule pas toujours tout seul. Et si je te disais qu'en réalité, ils ne t'en veulent pas ? Qu'ils sont là pour protéger quelqu'un, et que ce quelqu'un, c'est ton utilisateur ?

## Chaque requête traîne tes cookies

Pour comprendre CORS, il faut d'abord un fait tout bête. Quand ton navigateur fait une requête vers un domaine, il y joint automatiquement tous les cookies qu'il possède pour ce domaine. Tu appelles `mabanque.fr`, et le cookie de session que ta banque a déposé chez toi part avec la requête, sans que tu fasses quoi que ce soit. C'est même comme ça que tu restes connecté : le cookie voyage seul, le serveur le lit, il te reconnaît.

Pratique. Et un peu terrifiant, si on y réfléchit une seconde.

## Le scénario où on te fait les poches

Imagine un web sans aucune protection. Tu t'es connecté à ta banque ce matin, tu as donc encore ton cookie de session bien au chaud. Puis tu visites un site quelconque, qui a décidé de te dépouiller. Ce site charge du JavaScript qui, en douce, lance une requête vers `mabanque.fr/solde`.

Comme cette requête part vers le domaine de ta banque, elle emporte, automatiquement, ton cookie de session. Ta banque reçoit une requête parfaitement authentifiée, te reconnaît, et répond avec ton solde. Le site malveillant n'a jamais vu ni ton mot de passe ni ton cookie : il a juste profité du fait que ton navigateur, lui, les avait. Et il pourrait enchaîner tous les appels qu'il veut.

C'est exactement ce que le navigateur refuse de laisser arriver.

## La règle par défaut : on ne parle pas aux étrangers

Par défaut, un navigateur bloque les requêtes JavaScript vers un autre domaine que celui de la page en cours. Tu es sur `uneembrouille.com`, tu tentes un appel vers `mabanque.fr` : le navigateur met le holà et t'affiche la fameuse erreur rouge. C'est la politique de même origine, et cette erreur CORS que tu maudis, c'est elle qui parle.

Autrement dit, le rouge dans ta console n'est pas un bug. C'est le système qui fait son travail : empêcher, par défaut, n'importe quel site de se servir de la session bancaire ouverte dans ton autre onglet.

CORS, c'est simplement le mécanisme qui permet de faire une exception, proprement. Si une API veut autoriser un domaine précis à l'appeler, elle répond avec un en-tête, `Access-Control-Allow-Origin`, contenant ce domaine. Le navigateur voit l'autorisation explicite, et laisse passer. Deux sites qui travaillent ensemble s'entendent ainsi, sans ouvrir la porte à toute la rue.

## Le « correctif » qui désarme le garde du corps

Et c'est là que ça dérape, en général. Face à l'erreur rouge, la tentation est de la faire taire au plus vite. La façon la plus rapide : répondre `Access-Control-Allow-Origin: *`. L'étoile, ça veut dire « n'importe quel domaine peut m'appeler ». L'erreur disparaît, tu es content, tu passes à autre chose.

Sauf que tu viens de retirer la sécurité que CORS mettait en place. Pour une API vraiment publique et sans cookie, l'étoile est légitime. Mais la coller pour éteindre un voyant rouge sans comprendre ce qu'il protégeait, c'est débrancher le garde du corps parce qu'il t'a demandé ta pièce d'identité.

## Ce que l'IA te souffle un peu trop vite

Demande à un assistant de régler ton erreur CORS, et il ira souvent au plus court : mets une étoile, ou passe par un proxy qui contourne la restriction côté serveur. Ça marche, l'erreur s'en va. Mais la question qu'il ne pose pas, parce qu'il ne connaît pas ton contexte, c'est : cette porte, ai-je le droit de l'ouvrir aussi grand ? Y a-t-il, derrière, des cookies, des données sensibles, une session ? Ce jugement sur ce que tu protèges et pour qui ne se génère pas. La machine sait faire disparaître le rouge. Savoir si tu en as le droit, ça reste à toi.

## Ce que je te conseille

Quand tu tombes sur une erreur CORS, ne cherche pas d'abord à la faire taire. Demande-toi ce que le navigateur est en train de protéger. La plupart du temps, il fait exactement son boulot, et le bon correctif n'est pas de retirer le mur : c'est d'autoriser, côté serveur, le domaine précis qui en a besoin. L'étoile, garde-la pour les API réellement publiques, et en connaissance de cause.

Le rouge dans ta console n'est pas ton ennemi. C'est souvent le seul, dans l'histoire, qui se soucie de ton utilisateur pendant que tu te bats avec ta requête.

En marge du voyage d'une URL, dans le dossier [Navigateur](/dossier/browser). Le vocabulaire : les [CORS](/definition/cors) et le [cookie](/definition/cookie).


Ils sont tapis dans la console, prêts à te sauter au visage avec leurs grosses erreurs rouges. Et si les CORS ne t'en voulaient pas ? S'ils étaient là pour protéger, pas toi, mais ton utilisateur, de sa propre session ouverte dans l'onglet d'à côté ?

L'autodidacte

Cookie

Pourquoi les CORS veulent faire sauter ton navigateur ?