Symfony, largement utilisé dans l'écosystème PHP francophone, ne gère pas CORS nativement : il faut installer le bundle tiers nelmio/cors-bundle et configurer allow_origin dans config/packages/nelmio_cors.yaml. Une erreur classique consiste à laisser allow_origin: ['*'] hérité de la configuration de développement, ce qui fonctionne silencieusement jusqu'au jour où l'équipe active allow_credentials: true pour authentifier les requêtes via cookie de session — et le navigateur se met alors à rejeter les réponses.
La politique de même origine
Par défaut, les navigateurs appliquent la Same-Origin Policy : le code JavaScript d'une page provenant d'une origine (domaine + schéma + port) ne peut pas lire les réponses de requêtes faites vers une autre origine. C'est un mécanisme de sécurité fondamental qui empêche un script malveillant sur un site de voler des données d'un autre site où l'utilisateur est connecté.
Comment CORS assouplit cette politique
CORS (Cross-Origin Resource Sharing) est un ensemble d'en-têtes HTTP par lesquels un serveur autorise explicitement certaines origines externes (ou toutes) à lire ses réponses. L'en-tête clé est Access-Control-Allow-Origin, qui indique quels domaines sont autorisés.
Le piège du wildcard combiné aux credentials
Quand une requête est envoyée avec credentials: 'include' — nécessaire pour transmettre un cookie de session à une API sur un autre sous-domaine —, le navigateur refuse catégoriquement d'accepter Access-Control-Allow-Origin: * dans la réponse. La spécification interdit explicitement de combiner une origine générique avec des credentials ; le serveur doit renvoyer l'origine exacte de la requête.
Pourquoi c'est utile
- Diagnostiquer une erreur CORS et comprendre exactement quels en-têtes manquent côté serveur.
- Repérer une configuration
nelmio/cors-bundletrop permissive avant sa mise en production. - Comprendre la différence entre les requêtes « simples » et les requêtes preflight (OPTIONS).
CORS ne protège pas le serveur des attaques
C'est une idée reçue courante de penser que CORS est une mesure de sécurité côté serveur — en réalité, il ne restreint que ce que le JavaScript dans le navigateur peut lire. Un attaquant utilisant curl, Postman ou un script backend directement contourne entièrement CORS, car ces outils n'appliquent pas la politique de même origine. CORS ne doit jamais remplacer une authentification et une autorisation réelles côté serveur.