Expliquez la Same-Origin Policy et CORS.
Réponse courte
La Same-Origin Policy est la règle du navigateur selon laquelle un script d'une origine (schéma + hôte + port) ne peut pas lire les réponses d'une origine différente, ce qui protège les sessions authentifiées. CORS est un assouplissement contrôlé : un serveur renvoie des en-têtes Access-Control-Allow-Origin pour autoriser explicitement des origines spécifiques à lire ses réponses, ce qui assouplit la SOP au lieu de la contourner.
La Same-Origin Policy (SOP) est la limite de sécurité fondamentale du web. Sans elle, tout site que vous visitez pourrait lire silencieusement votre webmail, votre banque ou votre console d'administration connectés en utilisant vos propres cookies. La SOP empêche cela.
La Same-Origin Policy
Une origine est le triplet schéma + hôte + port (https://app.example.com:443). La SOP dit qu'un script s'exécutant dans une origine ne peut généralement pas lire la réponse d'une requête vers une origine différente. Notez la nuance : le navigateur va souvent quand même envoyer la requête intersite (c'est exactement pourquoi le CSRF existe), mais il empêche le script de lire le résultat. C'est ce qui empêche une page malveillante de récolter des données de vos sessions authentifiées ailleurs.
Pourquoi CORS existe
La SOP est délibérément stricte, mais les applications légitimes ont constamment besoin de données intersites — un front-end sur app.example.com appelant une API sur api.example.com. Cross-Origin Resource Sharing (CORS) est le mécanisme par lequel le serveur autorise le partage. Il assouplit la SOP de façon contrôlée ; il ne la désactive pas.
Comment fonctionne CORS
Le navigateur ajoute un en-tête Origin ; le serveur répond avec Access-Control-Allow-Origin nommant les origines autorisées à lire la réponse. Pour les requêtes qui peuvent modifier l'état ou utilisent des en-têtes/méthodes non simples, le navigateur envoie d'abord une requête de pré-vérification OPTIONS, et le serveur doit approuver la méthode et les en-têtes via Access-Control-Allow-Methods / -Headers avant que la vraie requête ne soit envoyée.
L'erreur de sécurité courante
Pour envoyer des cookies en intersite, vous devez définir Access-Control-Allow-Credentials: true — et dans ce cas la spécification interdit le joker Access-Control-Allow-Origin: * ; vous devez renvoyer une origine spécifique. Refléter naïvement l'Origin de la requête avec les identifiants activés est une mauvaise configuration classique qui laisse n'importe quel site lire les réponses authentifiées.
Les recruteurs recherchent la définition schéma/hôte/port, la subtilité « bloque la lecture, pas l'envoi », CORS comme autorisation du serveur qui assouplit (sans désactiver) la SOP, et le piège des identifiants combinés au joker.
Questions de suivi probables
- Qu'est-ce qui fait que deux URL sont « de même origine » ?
- Qu'est-ce qu'une requête de pré-vérification CORS et quand est-elle envoyée ?
- Pourquoi Access-Control-Allow-Origin : * avec des identifiants est-il interdit ?