CORS

CORS (Cross-Origin Resource Sharing) est le mécanisme du navigateur qui contrôle si JavaScript d’une origine peut lire les réponses d’une autre. Par défaut, les navigateurs bloquent les réponses XHR/fetch cross-origin — les en-têtes CORS du serveur déverrouillent un accès contrôlé.

Les deux principaux en-têtes de réponse :

• Access-Control-Allow-Origin : quelles origines peuvent lire la réponse. Soit une origine spécifique, soit * (toutes).
• Access-Control-Allow-Credentials : si les cookies peuvent circuler avec les requêtes cross-origin. true exige que l’origine soit spécifique, pas *.

Pour les requêtes qui ne sont pas “simples” (en-têtes personnalisés, méthodes non-GET/POST, corps JSON), le navigateur envoie d’abord une requête OPTIONS de preflight pour vérifier ce qui est autorisé. Le serveur répond avec Access-Control-Allow-Methods et Access-Control-Allow-Headers ; la vraie requête ne part que si le preflight réussit.

Idées reçues courantes : CORS n’est pas un mécanisme de sécurité côté serveur — c’est une restriction imposée par le navigateur qui protège les utilisateurs contre la lecture de données sur leur behalf depuis un autre site. Les serveurs peuvent toujours recevoir et traiter des requêtes cross-origin ; CORS contrôle uniquement si le navigateur retourne la réponse au JavaScript appelant.

Ce que “origine” signifie précisément : le triplet (schéma, hôte, port). http://example.com et https://example.com sont des origines différentes (schéma différent). https://api.example.com et https://example.com sont des origines différentes (sous-domaine différent). https://example.com:8080 et https://example.com sont des origines différentes (port différent). C’est la politique de même origine sur laquelle CORS ajoute des exceptions. Internet Explorer ignorait la partie port — une particularité qui a généré des années de bugs cross-navigateurs jusqu’à la retraite d’IE.

Pièges courants en production : le wildcard Access-Control-Allow-Origin: * bloque les credentials par spécification ; si vous avez besoin de cookies sur une requête cross-origin vous devez renvoyer l’en-tête Origin de la requête spécifiquement. Ajouter un en-tête Authorization fait passer la requête de “simple” à “preflightée”, doublant les allers-retours — mettre en cache le preflight via Access-Control-Max-Age (jusqu’à 7200 secondes dans Chrome, 600 dans Firefox) est la mitigation standard. Enfin, l’erreur CORS dans la console DevTools du navigateur est vraiment une décision du navigateur — les logs serveur montreront que la requête a atteint le backend et a été traitée normalement ; la réponse a simplement été ignorée côté client. Référence : WHATWG Fetch — Protocole HTTP-CORS.

Exemple concret : un POST JSON préfligué

Un SPA sur https://app.example.com envoie un POST JSON avec un token Bearer à https://api.example.com/v1/orders. Comme la requête utilise Content-Type: application/json et un en-tête Authorization, elle est non-simple. Le navigateur envoie d’abord OPTIONS /v1/orders avec Origin: https://app.example.com, Access-Control-Request-Method: POST, et Access-Control-Request-Headers: authorization,content-type. Le serveur répond 204 avec Access-Control-Allow-Origin: https://app.example.com, Access-Control-Allow-Methods: POST, Access-Control-Allow-Headers: authorization,content-type, et Access-Control-Max-Age: 600. Seulement ensuite le vrai POST est envoyé. Définir Max-Age: 600 évite le preflight pendant les 10 prochaines minutes, éliminant un aller-retour de chaque appel suivant — mesurable comme une réduction de 50-100 ms sur les liaisons transatlantiques.

Quand CORS ne suffit pas

CORS protège les utilisateurs des lectures cross-origin ; il ne protège pas les serveurs des requêtes indésirables. Les endpoints qui modifient l’état ont encore besoin de tokens CSRF ou de cookies SameSite, et l’authentification nécessite toujours une validation correcte des tokens côté serveur. Une API publique derrière Access-Control-Allow-Origin: * est accessible publiquement par n’importe qui — CORS a simplement permis au navigateur de le révéler. Pour un contexte architectural plus approfondi, voir la référence CORS de MDN, qui reflète la spécification WHATWG avec des exemples pratiques.