CORS mal configuré : la porte que vous ouvrez à tous les sites

Le principe

Par défaut, un navigateur empêche un site A de lire les réponses d’un site B pour son propre compte — c’est la règle de même origine. CORS (Cross-Origin Resource Sharing) est le mécanisme qui permet à un site d’autoriser explicitement certains autres sites à lire ses réponses malgré tout.

Le problème apparaît quand cette autorisation est donnée beaucoup trop largement, ou de façon mal pensée, au lieu d’être limitée à une liste précise de partenaires de confiance.

Un exemple concret

Une API répond systématiquement en reflétant l’origine qui a fait la demande, quelle qu’elle soit, combiné à l’autorisation d’envoyer les identifiants (cookies) avec la requête. N’importe quel site malveillant peut alors faire naviguer une victime dessus, déclencher une requête vers votre API AVEC ses cookies de session déjà valides, et LIRE la réponse renvoyée.

Résultat : vol de données personnelles, de factures, de jetons d’accès — entièrement invisible pour la victime, qui n’a rien cliqué d’explicite si ce n’est visiter une page piégée.

Pourquoi c’est grave

Un CORS mal réglé transforme chaque visiteur connecté de votre site en victime potentielle dès qu’il visite n’importe quel site malveillant ailleurs sur le web — pas besoin qu’il clique sur quoi que ce soit de spécifique une fois sur place.

Des variantes tout aussi dangereuses existent : accepter l’origine spéciale « null » (atteignable via une iframe sandboxée), ou valider par « commence par »/« contient » au lieu d’une égalité stricte, ce qui laisse un attaquant enregistrer un domaine piège ressemblant au vôtre.

Comment s’en protéger

Ne jamais refléter aveuglément l’origine reçue dans la réponse. Comparer l’origine à une liste blanche exacte, en égalité stricte — jamais une expression régulière mal échappée où un simple point non protégé finit par matcher n’importe quel caractère.

Ne jamais combiner le joker « * » avec l’autorisation d’envoyer les identifiants : la spécification l’interdit d’ailleurs explicitement, mais certaines configurations laissent encore passer la combinaison par erreur. Si l’API n’a structurellement pas besoin d’être appelée depuis un autre domaine, ne pas activer CORS du tout.

Comment SauronSec la détecte

Envoi d’une série d’origines contrôlées (domaine totalement étranger, origine « null », variantes de préfixe et de suffixe) et vérification exacte : le serveur renvoie-t-il cette origine précise en autorisation ? Chaque reflet positif est confirmé une seconde fois avant d’être signalé.

La présence ou non de l’autorisation d’envoyer les identifiants détermine la gravité réellement rapportée : un reflet sans cookies associés n’a pas le même impact concret qu’un reflet qui expose des données pleinement authentifiées.