CORS n'est pas une sécurité. C'est une politique de lecture du navigateur._

CORS est l'un des aspects les plus mal compris de la sécurité web car il se situe à proximité du contrôle d'accès sans en être réellement un.

Il indique au navigateur si le code frontend d'une origine est autorisé à lire une réponse d'une autre origine. C'est utile. Ce n'est pas la même chose que de décider si la requête devrait être autorisée en premier lieu.

Ce que fait CORS

CORS affecte principalement le comportement du navigateur :

• la requête peut-elle être effectuée normalement ?
• déclenche-t-elle un pré-vérification ?
• la réponse peut-elle être exposée au JavaScript frontend ?

C'est pourquoi un serveur peut encore recevoir une requête même si le navigateur bloque par la suite l'accès aux données de réponse.

C'est également pourquoi CORS ne fait rien pour les clients non-navigateur comme curl, les services backend, ou les applications mobiles. Ces clients ne respectent pas les règles d'origine du navigateur en premier lieu.

Ce qu'il ne fait pas

CORS ne remplace pas :

• l'authentification
• l'autorisation
• la protection contre le CSRF
• la validation côté serveur

Si votre seule protection est "le navigateur le bloquera à cause de CORS", le design n'est pas suffisamment sécurisé.

Un exemple concret

Cette configuration de headers peut être correcte pour une application de navigateur :

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true

Mais l'API réelle doit toujours valider si l'appelant est authentifié et autorisé à effectuer l'action. CORS ne répond pas à cette question pour vous.

Lecture complémentaire

• MDN : CORS
• MDN : Politique de même origine
• Fiche astuce OWASP pour la prévention du CSRF