flawopen.com/CSRF/Cookies SameSite
SameSite=Strict remplace-t-il les jetons CSRF ?
SameSite=Strict constitue une protection forte du navigateur pour les requêtes authentifiées par cookie provenant d’un autre site, mais ce n’est pas une défense universelle contre le CSRF. Les sous-domaines frères restent considérés comme le même site même s’ils ont des origines différentes, et les clients qui n’appliquent pas l’attribut ne sont pas protégés. Conservez un jeton CSRF ou une autre défense liée à l’origine de la requête lorsque le modèle de menace l’exige.
Ce que fait réellement SameSite
Un cookie SameSite=Strict n’est pas envoyé dans les requêtes cross-site, y compris le schéma CSRF classique où un autre site soumet un formulaire à votre application. Le navigateur n’ajoute donc pas automatiquement le cookie de session dans ce contexte. SameSite est défini au niveau du site, pas de l’origine : une requête provenant d’un sous-domaine frère peut rester same-site. Strict ne protège donc pas contre un hôte frère compromis ou non fiable. Strict peut aussi laisser l’utilisateur non authentifié après avoir suivi un lien externe, car le cookie n’est pas envoyé pendant cette navigation.
Ses limites restantes
Si l’authentification repose sur un bearer token que l’application place explicitement dans l’en-tête Authorization, SameSite ne contrôle pas cet en-tête. Le comportement automatique du navigateur pour les cookies est différent. Cela ne rend pas automatiquement toute conception sûre : vérifiez si un autre mécanisme peut joindre des justificatifs automatiquement et protégez les jetons contre le vol et l’usage abusif.
Un SameSite=Lax explicite autorise les requêtes same-site et les navigations de premier niveau cross-site avec une méthode sûre comme GET ; le cookie est omis pour les sous-requêtes cross-site et les navigations avec une méthode non sûre. Si l’attribut est omis, l’agent utilisateur applique sa valeur par défaut. Dans Chromium, cette valeur par défaut diffère de Lax explicite : l’implémentation actuelle autorise certains cookies sans attribut explicite dans les requêtes cross-site de premier niveau avec méthode non sûre pendant 2 minutes au maximum après leur création (Lax-allowing-unsafe). Ne comptez pas sur cette compatibilité propre au navigateur comme défense CSRF. Définissez explicitement l’attribut voulu, testez les clients pris en charge et ne rendez jamais une opération de modification accessible via une méthode sûre.
L’application de SameSite dépend du navigateur. Un client qui ne prend pas en charge l’attribut ou ne le respecte pas n’est pas protégé. Vérifiez les clients pris en charge et traitez SameSite comme une défense en profondeur, avec un jeton CSRF adapté, une validation de l’en-tête Origin ou une autre défense principale.
Questions fréquentes
Consultez le guide dédié aux méthodes sûres. Aucune action modifiant l’état ne doit être accessible par une méthode sûre comme GET ; ces méthodes sont censées ne pas modifier l’état du serveur.