Le CORS, c'est quoi ? Pourquoi mon navigateur bloque ma requête

Vous avez sûrement déjà croisé cette erreur rouge : « blocked by CORS policy ». Le CORS est une règle de sécurité du navigateur : une page web ne peut lire la réponse d'un autre site que si ce site l'y autorise explicitement.

D'où vient cette règle ?

Votre navigateur est votre portier. Quand vous êtes connecté à votre banque dans un onglet, il ne veut pas qu'un autre site, ouvert dans un second onglet, aille lire vos informations en votre nom.

Il applique donc un principe de base : une page ne lit que les réponses venant de sa propre origine. Une origine, c'est l'ensemble : le protocole (https), le nom de domaine et le port. Si l'un des trois change, c'est une autre origine.

Et quand c'est voulu ?

C'est très courant : votre site monsite.com affiche des données qui viennent de api.monsite.com. Deux origines différentes, pourtant le même propriétaire. Il faut donc un moyen de dire « celle-là, je la connais ».

C'est le CORS (partage de ressources entre origines). Le serveur ajoute dans sa réponse des en-têtes, de petites étiquettes, qui indiquent au navigateur quelles origines ont le droit de lire. Pour certaines requêtes, le navigateur pose d'abord la question au serveur (une requête « préliminaire »), et n'envoie la vraie qu'après une réponse favorable.

Ce que le CORS n'est pas

• Ce n'est pas un pare-feu. Il protège l'utilisateur dans son navigateur. Un autre programme peut appeler votre API sans passer par lui : votre API doit donc vérifier elle-même qui a le droit de faire quoi.
• Ce n'est pas un bug du front. L'autorisation se configure côté serveur. Retoucher le code de la page ne règle rien.

Les deux erreurs classiques

1. Tout autoriser pour que l'erreur disparaisse. C'est pratique en développement, mais cela supprime la protection. En production, on liste les origines réellement attendues.
2. Mélanger avec les cookies. Si les requêtes portent l'identité de l'utilisateur, le navigateur refuse l'autorisation « pour tout le monde » : il faut nommer les origines précisément.

À retenir

Le CORS ne bloque pas votre application : il demande au serveur de dire qui peut lire ses réponses. Autorisez les origines dont vous avez besoin, pas davantage, et ne comptez pas sur lui pour protéger vos données.

Et pour votre produit ?

Une configuration CORS trop large, copiée pour « faire marcher » une démo, passe souvent en production sans que personne n'y revienne. C'est le genre de détail qu'un audit de votre application vérifie, avec le reste des accès. Si vous voulez en parler, on peut échanger 30 minutes.

Pour aller plus loin : qu'est-ce qu'une API, les règles d'accès à une base de données et les failles fréquentes d'une application générée par IA.