Attributs de cookies sécurisés

Ce que vérifie ce contrôle

Lit chaque en-tête de réponse Set-Cookie et vérifie trois drapeaux :

• Secure — cookie envoyé uniquement sur HTTPS.
• HttpOnly — cookie non lisible depuis JavaScript (bloque le vol via XSS).
• SameSite=Lax|Strict|None — comportement sur les requêtes inter-sites (bloque le CSRF).

Le contrôle passe quand chaque cookie portant de l’authentification ou un état de session a les trois.

Pourquoi c’est important

Les cookies portent les clés des sessions de vos utilisateurs. Un cookie sans ces drapeaux est à une vulnérabilité XSS ou à un Wi-Fi hostile près du vol de compte :

• Pas de Secure → le cookie circule en HTTP en clair sur la première requête avant que HSTS ne prenne le relais. Captable sur le Wi-Fi d’un café.
• Pas de HttpOnly → tout script injecté (XSS, dépendance npm malveillante, pub hostile) peut lire le cookie via document.cookie et l’exfiltrer.
• Pas de SameSite → falsification de requête inter-sites (CSRF). Une page malveillante peut soumettre des formulaires ou déclencher des requêtes en tant qu’utilisateur connecté.

Les navigateurs ont durci leurs valeurs par défaut : Chrome livre désormais SameSite=Lax par défaut, mais le code historique qui définit explicitement des cookies sans drapeaux fuit toujours.

Comment corriger

Définissez chaque cookie de session/auth avec les trois drapeaux.

Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=86400

Express / Node.js :

res.cookie("session", token, {
  httpOnly: true,
  secure: true,
  sameSite: "lax",
  maxAge: 86400 * 1000,
  path: "/",
});

Next.js (App Router avec cookies()) :

import { cookies } from "next/headers";

cookies().set({
  name: "session",
  value: token,
  httpOnly: true,
  secure: true,
  sameSite: "lax",
  path: "/",
  maxAge: 86400,
});

Bun.serve() :

return new Response("ok", {
  headers: {
    "Set-Cookie": `session=${token}; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=86400`,
  },
});

Django :

# settings.py
SESSION_COOKIE_SECURE = True
SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_SAMESITE = "Lax"
CSRF_COOKIE_SECURE = True
CSRF_COOKIE_HTTPONLY = True
CSRF_COOKIE_SAMESITE = "Lax"

Rails :

# config/initializers/session_store.rb
Rails.application.config.session_store :cookie_store,
  key: "_app_session",
  secure: Rails.env.production?,
  httponly: true,
  same_site: :lax

PHP / WordPress : dans wp-config.php ou avant toute sortie :

ini_set('session.cookie_secure', '1');
ini_set('session.cookie_httponly', '1');
ini_set('session.cookie_samesite', 'Lax');

Quelle valeur de SameSite ?

• Strict — cookie jamais envoyé sur les requêtes inter-sites. Protection maximale, mais casse le cas où un utilisateur suit un lien vers votre site et arrive déconnecté. Bon pour les flux à fort enjeu (admin, banque).
• Lax (par défaut) — cookie envoyé sur les navigations de haut niveau (clic sur un lien) mais pas sur les POST inter-sites, iframes ou requêtes d’image. Le bon défaut pour la plupart des sites.
• None — cookie envoyé sur toutes les requêtes inter-sites. Nécessite Secure. À utiliser uniquement quand vous avez vraiment besoin d’un contexte tiers (widgets embarqués, fournisseurs d’identité).

Les préfixes de nom de cookie ajoutent une seconde couche d’application :

• __Secure- — le navigateur refuse de définir ce cookie si Secure n’est pas aussi présent.
• __Host- — le navigateur refuse à moins de Secure, Path=/ et aucun attribut Domain.

Set-Cookie: __Host-session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax

Associez cette règle à HTTPS, activer HSTS et la politique referrer pour une base complète de sécurité du transport.

Questions fréquentes

HttpOnly cassera-t-il mon code client ?

Seulement si vous lisez le cookie depuis JavaScript. Pour les cookies de session/auth, vous ne devriez pas — le cookie doit être opaque pour le client et utilisé uniquement par le serveur. Si vous stockez des données que le JS doit lire, c’est une catégorie de cookie différente (préférences, état UI) et HttpOnly ne s’applique pas.

Et les cookies de consentement et d’analytics ?

Les cookies de consentement et d’analytics ont souvent réellement besoin d’être lisibles par JavaScript. Définissez Secure et SameSite=Lax dessus, mais sautez HttpOnly. Le contrôle MetricSpot le tolère — il n’avertit que quand un cookie de session n’a pas les drapeaux.

Cela affecte-t-il directement la conformité RGPD ?

Pas le versant consentement / base légale, mais le versant sécurité. L’article 32 du RGPD exige des « mesures techniques appropriées » — l’absence de drapeaux sur les cookies est régulièrement citée dans les décisions des autorités de contrôle comme une faille de sécurité. Associez à une bannière de consentement cookies et une politique de confidentialité pour la couche légale.