CORS : éviter une configuration dangereuse

Comment fonctionne CORS

Quand un script tente d'accéder à une ressource d'une autre origine, le navigateur ajoute un en-tête Origin à la requête et vérifie la réponse du serveur. Si celle-ci contient un en-tête Access-Control-Allow-Origin qui autorise l'origine demandeuse, le navigateur laisse le script lire la réponse ; sinon, il la bloque. Pour les requêtes sensibles, le navigateur envoie même au préalable une requête de « pré-vol » (preflight, en méthode OPTIONS) pour vérifier l'autorisation.

Le point clé à comprendre : CORS n'est pas un contrôle d'accès côté serveur. Il indique seulement au navigateur ce qu'il a le droit d'exposer au JavaScript d'une autre origine. C'est donc une décision de confiance que vous déléguez, et qu'il faut calibrer avec soin.

Le combo à proscrire

La configuration dangereuse associe Access-Control-Allow-Origin: * (toutes les origines) avec Access-Control-Allow-Credentials: true (qui autorise l'envoi des cookies d'authentification). Cette combinaison exacte est d'ailleurs interdite par la spécification, mais certains serveurs la contournent en « reflétant » dynamiquement l'origine reçue dans la requête — ce qui revient exactement au même danger, en moins visible.

Concrètement, avec cette faille, un site malveillant que visite votre utilisateur connecté pourrait, en arrière-plan, faire des requêtes authentifiées vers votre API au nom de la victime et en lire les réponses : données personnelles, messages privés, informations de compte. Tout cela sans que la victime ne s'aperçoive de rien.

La bonne pratique

N'utilisez jamais le wildcard avec des credentials, ni le reflet aveugle de l'origine. Maintenez une liste explicite d'origines de confiance (côté application), et ne renvoyez l'en-tête Access-Control-Allow-Origin que si l'origine de la requête y figure. N'activez Allow-Credentials que pour ces origines, et ajoutez toujours Vary: Origin pour ne pas servir une réponse mise en cache à la mauvaise origine.

<IfModule mod_headers.c>
  Header always set Access-Control-Allow-Origin "https://app.exemple.com"
  Header always set Access-Control-Allow-Credentials "true"
  Header always set Vary "Origin"
</IfModule>

add_header Access-Control-Allow-Origin "https://app.exemple.com" always;
add_header Access-Control-Allow-Credentials "true" always;
add_header Vary "Origin" always;

Vérifier votre configuration

Testez la réaction de votre serveur en simulant une origine arbitraire. En ligne de commande : curl -I -H "Origin: https://attaquant.example" https://votreapi.fr/. Si la réponse renvoie Access-Control-Allow-Origin: https://attaquant.example (ou *) accompagné de Allow-Credentials: true, votre configuration est vulnérable. Une configuration saine n'autorise que vos origines légitimes. Relancez aussi un audit CheckCyber, qui signale les politiques CORS permissives.