1. Qu’est-ce que la Same-Origin Policy (SOP) ?
La Same-Origin Policy (SOP) est la frontière de sécurité fondamentale des navigateurs qui isole les contextes d’exécution. Elle interdit au JavaScript de https://banque.com d’accéder aux cookies ou réponses Fetch de https://malveillant.com.
Deux adresses ont la même origine si et seulement si leur Protocole, leur Hôte et leur Port sont strictement identiques :
https://api.example.com:443 vs https://example.com:443 → ORIGINES DIFFÉRENTES (Sous-domaine distinct)http://example.com:80 vs https://example.com:443 → ORIGINES DIFFÉRENTES (Protocole distinct : HTTP vs HTTPS)https://example.com/app vs https://example.com/api → MÊME ORIGINE (Chemins d’accès distincts autorisés)2. Comment le CORS Autorise l’Accès Cross-Origin Sécurisé
Le protocole CORS (Cross-Origin Resource Sharing) permet aux serveurs de stipuler explicitement quelles origines tierces peuvent lire leurs données grâce aux en-têtes de réponse HTTP :
- Access-Control-Allow-Origin : Indique les origines autorisées (ex. :
https://app.curious-techie.com). - Access-Control-Allow-Methods : Méthodes HTTP permises (ex. :
GET, POST, PUT, DELETE). - Access-Control-Allow-Headers : En-têtes autorisés (ex. :
Content-Type, Authorization). - Access-Control-Max-Age : Durée de mise en cache du preflight OPTIONS en secondes.
3. Requêtes Préliminaires OPTIONS (Preflight) & Cache
Pour les requêtes complexes (envoi de JSON avec Content-Type: application/json ou en-têtes d’authentification), le navigateur émet automatiquement une requête préalable HTTP OPTIONS (preflight) avant de transmettre le corps.
4. Le Piège des Identifiants et Caractères Génériques (*)
Un piège de sécurité récurrent lors du partage de sessions authentifiées entre origines :
Les navigateurs refusent catégoriquement d’exposer la réponse si le joker * est combiné à des identifiants. Le serveur doit retourner l’origine exacte validée.