Cookies sans flags Secure / HttpOnly / SameSite
Trois attributs déterminent qui peut lire, voler, ou rejouer un cookie. Sans eux, un cookie de session — souvent la seule chose qui sépare un visiteur anonyme d'un compte connecté — devient vulnérable.
Secure
Sans cet attribut, le cookie peut être transmis sur une connexion HTTP non chiffrée si jamais une requête part accidentellement en HTTP (lien mal formé, ancienne ressource) — exposant sa valeur en clair sur le réseau.
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=LaxHttpOnly
Sans cet attribut, le cookie est accessible via document.cookie en JavaScript. Si une faille XSS existe ailleurs sur le site (même dans une librairie tierce), un script injecté peut lire et exfiltrer directement le cookie de session.
SameSite
Sans cet attribut, le navigateur envoie le cookie même sur des requêtes déclenchées depuis un autre site — le terrain classique d'une attaque CSRF (un site malveillant fait agir ton utilisateur connecté à son insu, sur ton site).
Strict— le plus sûr, mais casse la navigation si un lien externe mène vers une page qui a besoin du cookie.Lax— bon compromis par défaut, protège contre la plupart des attaques CSRF tout en gardant la navigation normale.
Où corriger ça
Ces attributs se règlent où le cookie est créé — le framework d'auth (NextAuth, Supabase Auth...), ou ton propre code si tu gères les sessions à la main. Vérifie la configuration de session de ton framework plutôt que d'essayer d'intercepter et modifier les cookies après coup.
Vérifie si ton site est concerné par cette faille.
Scanner mon app