CHECKCYBER

Sécuriser ses cookies : Secure, HttpOnly et SameSite

Les cookies, et tout particulièrement ceux de session, sont une cible de premier choix pour les attaquants. La raison est simple : qui vole le cookie de session d'un utilisateur connecté peut se faire passer pour lui sans connaître son mot de passe, le temps que la session reste valide. C'est ce qu'on appelle le détournement de session.

La bonne nouvelle, c'est que trois attributs simples — Secure, HttpOnly et SameSite — réduisent drastiquement ce risque, chacun fermant un vecteur d'attaque différent. Ils s'ajoutent à la déclaration du cookie, sans modifier votre logique applicative. Pourtant, beaucoup de sites les oublient, laissant leurs cookies de session exposés.

À quoi sert chaque attribut

Secure garantit que le cookie n'est transmis que sur une connexion HTTPS chiffrée, jamais en clair : il ne pourra donc pas être capté par un tiers qui écoute le réseau. HttpOnly rend le cookie inaccessible au JavaScript de la page, ce qui empêche son vol via une faille XSS — le vecteur le plus courant de détournement de session. SameSite, enfin, contrôle si le cookie est envoyé lors de requêtes provenant d'autres sites, ce qui bloque la plupart des attaques CSRF (où un site malveillant déclenche une action sur le vôtre à l'insu de l'utilisateur connecté).

Ces trois attributs sont complémentaires : chacun couvre un angle d'attaque distinct, et c'est leur combinaison qui protège réellement le cookie.

Bien choisir la valeur de SameSite

SameSite=Lax est le bon défaut pour la grande majorité des sites : il bloque l'envoi du cookie sur les requêtes inter-sites silencieuses (formulaires, images), tout en l'autorisant lors d'une navigation de premier niveau, comme un clic sur un lien externe menant à votre site — l'utilisateur reste ainsi connecté.

SameSite=Strict est plus protecteur encore, mais peut gêner certains parcours : un utilisateur arrivant sur votre site depuis un lien externe apparaîtra déconnecté lors de cette première page. Réservez-le aux cookies très sensibles. À l'inverse, SameSite=None (qui autorise tous les contextes inter-sites) exige obligatoirement l'attribut Secure et ne doit être utilisé que si vous avez un réel besoin de cookies tiers.

Comment les appliquer

Sur un site en PHP (cas fréquent sur hébergement mutualisé), le plus simple est de configurer globalement les cookies de session. Sur WordPress, la sécurisation des cookies d'authentification passe surtout par l'activation complète du HTTPS (l'attribut Secure est alors ajouté automatiquement aux cookies d'admin).

PHP — php.ini ou .user.ini
; php.ini
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = "Lax"
PHP — à l’exécution (avant session_start)
session_set_cookie_params([
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Lax',
]);
session_start();
En-tête Set-Cookie (référence)
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax

Vérifier vos cookies

Ouvrez les outils de développement du navigateur (F12), onglet « Application » (ou « Stockage ») → « Cookies » : chaque cookie y affiche ses colonnes Secure, HttpOnly et SameSite. Vos cookies de session doivent avoir les trois correctement renseignés. Vous pouvez aussi relancer un audit CheckCyber, qui signale les cookies dépourvus de ces attributs.

[ FAQ // QUESTIONS FRÉQUENTES ]

Quelle différence entre SameSite=Lax et Strict ?

Lax autorise l'envoi du cookie lors d'une navigation de premier niveau depuis un autre site (clic sur un lien menant chez vous) ; Strict le bloque même dans ce cas, si bien que l'utilisateur paraît déconnecté à son arrivée. Lax est le bon compromis pour la plupart des sites.

HttpOnly empêche-t-il vraiment le vol de cookie ?

Il empêche le vol via JavaScript, qui est le vecteur le plus courant (lié au XSS). Il ne protège pas contre une interception réseau ni contre un accès physique à la machine — d'où l'importance de le combiner avec Secure et HTTPS pour une protection complète.

Dois-je sécuriser tous les cookies ou seulement ceux de session ?

Priorité absolue aux cookies de session et d'authentification, les plus sensibles. Mais appliquer Secure et HttpOnly par défaut à l'ensemble de vos cookies est une bonne pratique : seuls ceux qui doivent vraiment être lus par du JavaScript côté client justifient une exception.

[ PASSEZ À L’ACTION ]

Votre site est-il concerné ?

Lancez un audit de surface gratuit et obtenez en quelques secondes la liste exacte de vos failles, avec le correctif pour chacune. Anonyme, sans inscription.

▶ Auditer mon site

[ À LIRE AUSSI ]

[ CheckCyber // MIS À JOUR LE 2026-06-29 ]