CORS est une fonctionnalité de sécurité mise en œuvre par les navigateurs qui contrôle la manière dont les pages Web d'un domaine peuvent demander et interagir avec les ressources d'un autre domaine. Elle permet d'empêcher les accès interdomaines non autorisés tout en autorisant le partage légitime de données interdomaines. CORS utilise des en-têtes HTTP pour établir un dialogue entre les navigateurs et les serveurs, déterminant si les requêtes interdomaines doivent être autorisées en fonction de l'origine et d'autres facteurs.
Le partage de ressources entre origines (CORS, pour Cross-Origin Resource Sharing) est l'exception contrôlée à la politique de même origine. Il permet à un serveur de choisir de partager ses réponses avec des scripts d'autres origines en renvoyant des en-têtes HTTP spécifiques. Pour les requêtes simples, le navigateur envoie un en-tête Origin et vérifie l'Access-Control-Allow-Origin de la réponse avant de laisser le script appelant lire le corps. Pour les méthodes ou en-têtes susceptibles de modifier l'état, le navigateur envoie d'abord une requête de préparation (preflight) OPTIONS, et le serveur doit approuver la méthode, les en-têtes et l'origine. Lorsque des identifiants comme les cookies sont impliqués, le serveur doit définir Access-Control-Allow-Credentials: true et renvoyer une origine spécifique plutôt qu'un caractère générique. Le navigateur applique l'ensemble de ces règles.
CORS est fréquemment assoupli jusqu'à ce que les requêtes cessent d'échouer, ce qui démantèle discrètement les protections de même origine autour de points de terminaison sensibles. Refléter l'en-tête Origin de la requête dans Access-Control-Allow-Origin tout en autorisant aussi les identifiants permet en pratique à n'importe quel site de lire des réponses authentifiées pour le compte d'une victime connectée, exposant des données de compte ou des jetons. Faire confiance à un caractère générique, à une expression régulière trop large qui correspond à des sous-domaines contrôlés par l'attaquant, ou à l'origine littérale null sont des erreurs courantes. Comme la faille est invisible en usage normal et n'apparaît que lorsqu'elle est exploitée, un CORS permissif sur une API constitue un véritable vecteur d'exposition de données plutôt qu'un simple réglage cosmétique.
Maintenez une liste d'autorisation explicite d'origines de confiance et comparez l'Origin entrant à celle-ci de façon exacte plutôt que de refléter ce qui arrive. Ne combinez jamais un caractère générique avec des requêtes utilisant des identifiants, évitez d'autoriser l'origine null, et limitez les règles permissives à l'ensemble le plus restreint de chemins et de méthodes qui en ont réellement besoin. Gardez une mise en cache des préparations (Access-Control-Max-Age) raisonnable et revérifiez les politiques lorsque de nouveaux sous-domaines apparaissent. CORS est un mécanisme neutre de la plateforme web, la principale défense est donc une configuration serveur correcte accompagnée d'une revue ; une couche de surveillance côté client la complète en observant le comportement des scripts tiers, mais CORS lui-même relève des points de terminaison que vous contrôlez.
Pas directement. CORS est appliqué par le navigateur et détermine si un script peut lire une réponse cross-origin ; il n'empêche pas des clients non-navigateurs comme curl ou un proxy côté serveur de lire votre API. Il protège les utilisateurs contre la lecture de leurs réponses authentifiées par d'autres sites, pas le serveur contre les appels.
Le navigateur envoie une préparation pour les requêtes qui ne sont pas simples, par exemple celles utilisant PUT ou DELETE, des en-têtes personnalisés ou certains types de contenu. Il demande au serveur, via des en-têtes, si la méthode, les en-têtes et l'origine réels sont autorisés avant d'envoyer la vraie requête, ce qui empêche des appels inattendus modifiant l'état.
We answer client-side security questions every day. Bring yours.