Pourquoi CORS existe dans le navigateur
Les navigateurs appliquent la politique de meme origine pour empecher les sites malveillants de lire des donnees sensibles d'autres domaines. CORS assouplit cette restriction de maniere controlee en permettant aux serveurs de declarer quelles origines, methodes et en-tetes sont autorises. Sans en-tetes CORS, toute requete fetch ou XMLHttpRequest cross-origin sera bloquee, meme si le serveur a traite la requete avec succes.
Comprendre les en-tetes CORS
L'en-tete Access-Control-Allow-Origin specifie les origines de confiance. Access-Control-Allow-Methods liste les methodes HTTP autorisees comme GET, POST et DELETE. Access-Control-Allow-Headers declare quels en-tetes de requete personnalises sont acceptes. Access-Control-Expose-Headers controle quels en-tetes de reponse le navigateur peut lire, et Access-Control-Max-Age met en cache les resultats preflight pour reduire la latence.
Requetes simples vs preflight
Les requetes simples utilisent GET, HEAD ou POST avec des types de contenu standard et sautent l'etape preflight. Toute requete utilisant d'autres methodes, des en-tetes personnalises ou des types de contenu non standard declenche un appel OPTIONS preflight. Le serveur doit repondre au preflight avec les bons en-tetes CORS avant que le navigateur n'envoie la requete reelle.
Pieges courants et bonnes pratiques
Evitez d'utiliser des origines joker en production; etablissez une liste blanche de domaines specifiques. Ne combinez jamais des origines joker avec des identifiants car les navigateurs rejetteront la reponse. Definissez un Max Age raisonnable pour reduire la surcharge preflight sans mettre en cache des politiques obsoletes. Testez toujours CORS depuis l'origine reelle du client.
