Scanner de cookies non sécurisés

Comment fonctionne cette vérification

Scanaris lit les en-têtes Set-Cookie que ton serveur envoie au chargement de la page d'accueil et examine les attributs de chaque cookie. Il vérifie trois choses : qu'il porte Secure (exigé seulement si le site est en HTTPS), qu'il porte HttpOnly et qu'il déclare SameSite. Si le nom du cookie évoque une session ou une authentification (session, auth, token, sid et similaires), le constat est de sévérité moyenne ; sinon faible. Il y a un cas spécial avec sa propre sévérité moyenne : SameSite=None sans Secure, que les navigateurs modernes rejettent purement et simplement, donc le cookie ne fonctionne pas et trahit en plus une configuration pensée pour un usage entre sites. Seuls les cookies envoyés dans cette première réponse sont vus ; ceux créés après la connexion se vérifient mieux avec la commande plus bas ou avec le scan authentifié.

Ce que signifie chaque attribut

• Secure : le cookie ne voyage qu'en HTTPS. Sans lui, une requête en HTTP (un vieux lien, un réseau public) l'envoie en clair et n'importe qui sur le réseau le lit.
• HttpOnly : JavaScript ne peut pas le lire. C'est la différence entre un XSS qui vole la session et un XSS qui ne le peut pas.
• SameSite : quand il est envoyé depuis un autre site. Lax l'envoie lors des navigations normales mais pas sur des requêtes lancées par un autre site ; Strict jamais depuis l'extérieur ; None toujours, et exige Secure. C'est la défense principale contre le CSRF.

Ce qu'un attaquant fait d'un cookie de session sans ces attributs

Sans HttpOnly, tout script injecté lit document.cookie, envoie la valeur à son serveur et se connecte avec ta session. Sans SameSite, une page étrangère peut soumettre un formulaire à ton site avec le cookie joint et passer une commande ou changer un e-mail au nom de l'utilisateur. Sans Secure, il suffit que l'utilisateur ouvre un lien http:// vers ton domaine sur un réseau partagé. Dans les trois cas, le résultat est le même : quelqu'un agit en tant que ton utilisateur.

Comment corriger selon ton framework

// Express avec express-session
app.use(session({
  cookie: { secure: true, httpOnly: true, sameSite: 'lax' }
}));

// Next.js (Route Handler ou Server Action)
cookies().set('session', value, { httpOnly: true, secure: true, sameSite: 'lax', path: '/' });

// Nuxt (server/api)
setCookie(event, 'session', value, { httpOnly: true, secure: true, sameSite: 'lax', path: '/' });

Avec Supabase dans une appli dotée d'un serveur, la bibliothèque @supabase/ssr stocke la session dans des cookies avec ces attributs ; dans une SPA pure, la session va dans localStorage, ce que mesure la vérification jetons dans le storage. En Django, Rails ou Laravel, les attributs se configurent dans les réglages de session et sont raisonnables par défaut ; vérifie que personne ne les a baissés pour « régler » un problème de développement.

Vérifie que c'est corrigé

curl -sI https://tondomaine.com | grep -i "set-cookie"
curl -sI -X POST https://tondomaine.com/api/login -d "..." | grep -i "set-cookie"

Chaque cookie de session doit afficher Secure; HttpOnly; SameSite=Lax (ou Strict). Si ta connexion passe par un formulaire, regarde la réponse dans les outils du navigateur, onglet Réseau, en-têtes de réponse.

Questions fréquentes

Mon cookie est créé par JavaScript (analytique, préférences). Il ne peut pas être HttpOnly.

Exact, et ce n'est pas grave : ces cookies ne donnent accès à rien. La vérification le signale en sévérité faible pour l'attribut manquant ; ce qui compte, c'est que ceux de session l'aient.

J'ai besoin de SameSite=None parce que mon appli tourne dans un iframe sur un autre domaine.

Alors c'est légitime, toujours avec Secure. Assure-toi que les autres défenses contre le CSRF (jetons dans les formulaires, vérification de l'Origin) sont actives, parce que SameSite ne te protège plus.

Lax ou Strict ?

Lax pour la plupart des cas : il garde la session quand l'utilisateur arrive depuis un lien externe. Strict si le cookie donne accès à quelque chose de très sensible et que tu acceptes que l'utilisateur doive se reconnecter en arrivant de l'extérieur.