CORS mal configuré : les pièges du joker et du reflet
Le Cross-Origin Resource Sharing (CORS) contrôle quels autres sites peuvent lire les réponses de votre API. Une politique avec joker ou origine reflétée peut permettre à n’importe quel site d’effectuer des requêtes authentifiées et d’en lire les résultats.
Ce que c’est
Par défaut, les navigateurs bloquent les lectures cross-origin. Les en-têtes CORS assouplissent cela de façon sélective. Access-Control-Allow-Origin: * ouvre les réponses à tous les sites.
Un bug plus subtil est le reflet d’origine : le serveur renvoie dans l’en-tête allow-origin l’Origin qu’il a reçu, ce qui revient à faire confiance à tout le monde tout en paraissant spécifique.
Pourquoi ça compte
Si votre API sert des données utilisateur et autorise les credentials, une politique CORS trop large permet à un site malveillant de lire les données d’une victime connectée directement depuis votre API.
Le reflet combiné à Access-Control-Allow-Credentials: true est particulièrement dangereux — il annule la protection de même origine qui garde normalement les données utilisateur privées.
Comment corriger
Validez l’Origin de la requête contre une liste fixe de domaines de confiance, et ne le renvoyez qu’ensuite.
const ALLOWED = new Set(["https://app.yourdomain.com"]);
const origin = req.headers.get("origin") ?? "";
const allow = ALLOWED.has(origin) ? origin : "";
// only set the header when allow is non-emptyLes navigateurs interdisent Access-Control-Allow-Origin: * avec des credentials, alors certaines apps reflètent l’origine à la place — et c’est précisément la vulnérabilité. Utilisez plutôt une liste d’autorisations stricte.
Si un endpoint n’a pas besoin d’accès cross-origin, n’envoyez aucun en-tête CORS. N’ouvrez que les routes précises qui en ont réellement besoin.
FAQ
Access-Control-Allow-Origin: * est-il toujours mauvais ?
Pas pour des ressources réellement publiques et sans credentials (p. ex. une police publique ou une API de données ouvertes). C’est dangereux pour tout ce qui est lié à une session utilisateur.
CORS protège-t-il mon serveur ?
Non — CORS est appliqué par le navigateur, pas par le serveur. Il régit ce que le JavaScript des autres sites peut lire, pas le fait qu’une requête vous parvienne.
Votre app est-elle concernée ?
AppSafe détecte ce problème et des dizaines d’autres en un seul scan gratuit.
Scanner mon app gratuitementGuides liés
Les attributs de cookies Secure, HttpOnly et SameSite
Trois attributs qui empêchent le vol des cookies de session.
Content-Security-Policy (CSP) : ce que c’est et comment en ajouter une
L’en-tête qui empêche les scripts injectés de s’exécuter.
API keys exposées dans le JavaScript côté client
Tout ce qui est dans votre bundle est public. Traitez-le comme tel.