Cybendium - Guide francophone cybersécurité

CORS, CSRF et les cookies sont au cœur de la sécurité web côté navigateur. Ils expliquent comment une page peut appeler une API, comment une session est transportée et comment certaines actions peuvent être abusées.

Same-Origin Policy

La Same-Origin Policy limite ce qu'une page web peut lire depuis une autre origine.

Une origine est composée de :

protocole
domaine
port

https://example.com:443
│       │           │
│       │           └── Port
│       └────────────── Domaine
└────────────────────── Protocole

Deux URLs avec des domaines, ports ou protocoles différents ne sont pas de la même origine.

CORS

CORS signifie Cross-Origin Resource Sharing. C'est un mécanisme qui permet à un serveur d'autoriser explicitement certaines requêtes depuis une autre origine.

Exemple de header :

Access-Control-Allow-Origin: https://app.example.com

CORS contrôle surtout ce que le navigateur autorise une page à lire. Ce n'est pas un pare-feu serveur et ce n'est pas un système d'authentification.

À retenir

Une mauvaise configuration CORS peut exposer des données à des sites non prévus, surtout si elle est combinée avec des cookies ou des tokens.

Préflight

Pour certaines requêtes sensibles, le navigateur envoie d'abord une requête OPTIONS appelée préflight.

OPTIONS /api/profile HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: POST

Le serveur répond avec les méthodes, headers et origines autorisés.

Cookies

Les cookies transportent souvent une session ou une préférence.

Attributs importants :

Attribut	Rôle
`HttpOnly`	Empêche l'accès au cookie via JavaScript
`Secure`	Envoie le cookie uniquement en HTTPS
`SameSite`	Limite certains envois cross-site
`Max-Age`	Définit la durée de vie
`Path`	Limite le chemin concerné
`Domain`	Limite le domaine concerné

Un cookie de session doit être considéré comme un secret.

CSRF

CSRF signifie Cross-Site Request Forgery. L'idée est de pousser le navigateur d'une victime connectée à envoyer une requête vers un site où elle a déjà une session.

Victime connectée
      │
Site malveillant
      │
Requête envoyée vers le site légitime

Le risque dépend notamment de l'utilisation des cookies, des méthodes HTTP, de SameSite et de la présence d'un token anti-CSRF.

Protections CSRF

Protections courantes :

utiliser SameSite=Lax ou SameSite=Strict quand c'est possible
ajouter un token anti-CSRF pour les actions sensibles
vérifier l'origine avec Origin ou Referer
éviter les actions destructrices en GET
demander une confirmation pour les opérations critiques
réauthentifier pour les actions très sensibles

Erreurs fréquentes

croire que CORS protège une API contre tous les clients
mettre Access-Control-Allow-Origin: * avec des données sensibles
oublier HttpOnly sur un cookie de session
utiliser des actions sensibles en GET
ne pas protéger les changements d'email ou mot de passe
exposer des tokens dans du JavaScript public

Lecture défensive

Quand tu analyses une application, vérifie :

les cookies de session
les attributs Secure, HttpOnly et SameSite
les headers CORS
les requêtes OPTIONS
les actions sensibles
la présence d'un token anti-CSRF
les domaines autorisés

À retenir

CORS décide ce qu'un navigateur peut lire entre origines. CSRF abuse des sessions envoyées automatiquement. Les cookies doivent donc être configurés avec soin.