Pourquoi CORS existe dans le navigateur
Les navigateurs appliquent la politique de même origine pour empêcher les sites malveillants de lire des données sensibles d'autres domaines. CORS assouplit cette restriction de manière contrôlée en permettant aux serveurs de déclarer quelles origines, méthodes et en-tetes sont autorises. Sans en-tetes CORS, toute requête fetch ou XMLHttpRequest cross-origin sera bloquee, même si le serveur a traité la requête avec succès.
Comprendre les en-tetes CORS
L'en-tete Access-Control-Allow-Origin spécifié les origines de confiance. Access-Control-Allow-Methods liste les méthodes HTTP autorisées comme GET, POST et DELETE. Access-Control-Allow-Headers declare quels en-tetes de requête personnalises sont acceptes. Access-Control-Expose-Headers contrôle quels en-tetes de réponse le navigateur peut lire, et Access-Control-Max-Age met en cache les résultats preflight pour réduire la latence.
Requêtes simples vs preflight
Les requêtes simples utilisent GET, HEAD ou POST avec des types de contenu standard et sautent l'étape preflight. Toute requête utilisant d'autres méthodes, des en-tetes personnalises ou des types de contenu non standard declenche un appel OPTIONS preflight. Le serveur doit répondre au preflight avec les bons en-tetes CORS avant que le navigateur n'envoie la requête reelle.
Pieges courants et bonnes pratiques
Évitez d'utiliser des origines joker en production; etablissez une liste blanche de domaines spécifiques. Ne combinez jamais des origines joker avec des identifiants car les navigateurs rejetteront la réponse. Définissez un Max Age raisonnable pour réduire la surcharge preflight sans mettre en cache des politiques obsoletes. Testez toujours CORS depuis l'origine reelle du client.
