Sécuriser les cookies de votre site avec Secure, HttpOnly et SameSite

Des cookies sécurisés portent trois attributs, Secure, HttpOnly et SameSite, qui indiquent au navigateur comment les protéger. Notre audit lit les en-têtes Set-Cookie de la page principale et signale chaque attribut manquant. Chaque correction se fait là où le cookie est créé : le code de l'application, la configuration de la session, ou le plugin qui le pose.

Ce que fait chaque attribut

• Secure : le cookie n'est envoyé que sur une connexion HTTPS. L'audit ne le réclame que si la page est servie en HTTPS.
• HttpOnly : un script JavaScript ne peut pas lire le cookie. Une faille d'injection de script ne permet alors pas de voler une session.
• SameSite : limite l'envoi du cookie lors de requêtes venues d'un autre site, ce qui réduit les risques de CSRF. Lax convient à la plupart des sites, Strict est plus restrictif, None exige Secure et ne doit servir que pour un usage volontairement inter-sites.

Corriger dans le code de l'application

PHP natif

setcookie('nom_du_cookie', $valeur, [
    'expires'  => time() + 3600,
    'path'     => '/',
    'secure'   => true,
    'httponly' => true,
    'samesite' => 'Lax',
]);

Pour le cookie de session, dans php.ini :

session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = "Lax"

Symfony

# config/packages/framework.yaml
framework:
    session:
        cookie_secure: true
        cookie_httponly: true
        cookie_samesite: lax

Corriger au niveau du serveur

Si vous ne pouvez pas modifier le code, le serveur peut ajouter les attributs aux réponses. C'est un pis-aller : préférez toujours la correction à la source.

Nginx, pour les réponses transmises par proxy_pass (version 1.19.3 ou plus récente) :

proxy_cookie_flags ~ secure httponly samesite=lax;

Apache, avec mod_headers, uniquement si aucun cookie ne porte déjà ces attributs (sinon ils seraient dupliqués) :

Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure;SameSite=Lax

Cas des cookies lus par JavaScript

Un cookie que votre propre script doit lire, par exemple l'état d'une bannière de consentement, ne peut pas être HttpOnly. Gardez cet attribut pour les cookies de session et d'authentification, et laissez Secure et SameSite sur tous les cookies.

Le préfixe __Host- ou __Secure-

L'audit relève en information, sans pénalité, les cookies dont le nom n'a pas ces préfixes. Un cookie nommé __Host-session est rejeté par le navigateur s'il n'a pas Secure, Path=/ et aucun attribut Domain : la protection ne dépend plus d'une configuration qu'un changement futur pourrait casser. Il faut renommer le cookie dans le code qui le pose.

Sous WordPress

Les cookies du cœur de WordPress sont gérés par le noyau. Ceux qui sont signalés viennent presque toujours d'un plugin ou d'un service tiers : repérez leur nom dans le constat, retrouvez le plugin correspondant et regardez ses réglages, ou contactez son support.

Vérifier

Ouvrez les outils du navigateur, onglet Application ou Stockage, puis Cookies : les colonnes Secure, HttpOnly et SameSite doivent être renseignées. Relancez l'audit pour confirmer que les constats disparaissent. Les cookies de suivi déposés avant consentement relèvent d'un autre sujet, traité dans le guide RGPD, cookies et consentement. L'ensemble des en-têtes de protection est décrit dans le guide en-têtes de sécurité HTTP.