Qu'est-ce que les indicateurs de sécurité des cookies ?

Chaque fois que votre site WordPress définit un cookie (que ce soit pour les sessions de connexion, les paniers d'achat, les analyses ou les préférences de consentement), ce cookie peut transporter un ensemble d'indicateurs de sécurité. Ces indicateurs disent au navigateur comment gérer le cookie : quand l'envoyer, qui peut le lire et sur quelles connexions il peut transiter. Les configurer incorrectement ne casse rien de visible, mais ouvre la porte à des attaques que la plupart des propriétaires de sites ne remarquent jamais avant qu'il ne soit trop tard.

L'indicateur Secure : des cookies uniquement en HTTPS

Un cookie portant l'indicateur Secure ne sera transmis que sur les connexions HTTPS. Le navigateur refuse simplement de l'inclure dans toute requête HTTP non chiffrée.

Set-Cookie: session_id=abc123; Secure

Pourquoi est-ce important ? Imaginez un visiteur accédant à votre site depuis le Wi-Fi d'un café. S'il charge une page en HTTP simple (peut-être via un ancien marque-page ou une mauvaise configuration de redirection), ses cookies voyageraient normalement en clair sur le réseau. Quiconque écoute le trafic Wi-Fi pourrait récupérer le cookie de session et usurper l'identité de l'utilisateur. Avec l'indicateur Secure, le navigateur retient entièrement le cookie dans ce scénario.

Puisque votre site WordPress devrait de toute façon fonctionner en HTTPS (et il le devrait, il n'y a plus d'excuse en 2025), définir cet indicateur ne coûte rien et empêche une véritable catégorie d'attaques.

L'indicateur HttpOnly : protection contre les XSS

L'indicateur HttpOnly empêche JavaScript d'accéder au cookie via document.cookie. Le cookie est toujours envoyé normalement avec les requêtes HTTP, mais aucun script côté client ne peut le lire ou le manipuler.

Set-Cookie: session_id=abc123; HttpOnly

Cet indicateur existe spécifiquement pour limiter les dégâts des attaques Cross-Site Scripting (XSS). Si un attaquant parvient à injecter du JavaScript dans votre page (via une extension vulnérable, un champ de commentaire ou un vecteur XSS stocké), l'une des premières choses que ce script tentera est document.cookie pour voler les jetons de session. Avec HttpOnly en place, cet appel ne renvoie rien pour les cookies protégés.

Cela n'empêche pas le XSS lui-même. Cela ne corrige pas la vulnérabilité sous-jacente. Mais cela retire le butin le plus précieux (les cookies de session) de la table, ce qui fait souvent la différence entre une nuisance et une prise de contrôle complète du compte.

L'indicateur SameSite : protection contre le CSRF

L'attribut SameSite contrôle le comportement des cookies inter-sites. Il détermine si le navigateur envoie un cookie lorsque la requête provient d'un domaine différent de celui qui l'a défini.

Trois valeurs sont possibles :

• SameSite=Strict : le cookie n'est jamais envoyé avec les requêtes inter-sites. Point. Si quelqu'un clique sur un lien vers votre site depuis une page externe, son cookie de session ne sera pas inclus dans cette première requête. C'est le paramètre le plus restrictif et il peut causer des problèmes d'utilisabilité (les utilisateurs apparaissent déconnectés en arrivant via des liens externes).
• SameSite=Lax : le cookie est envoyé avec les navigations de premier niveau (clic sur un lien) mais pas avec les requêtes intégrées comme les images, iframes ou soumissions de formulaires depuis d'autres sites. C'est le réglage par défaut du navigateur depuis Chrome 80 (2020) et offre un bon équilibre entre sécurité et utilisabilité.
• SameSite=None : le cookie est envoyé avec toutes les requêtes, quelle que soit l'origine. Cela est nécessaire pour les cas d'usage légitimes de cookies tiers (formulaires de paiement intégrés, SSO, publicité), mais doit toujours être combiné à l'indicateur Secure, car les navigateurs rejettent SameSite=None sans Secure.

Set-Cookie: session_id=abc123; SameSite=Lax

La principale menace traitée par SameSite est le Cross-Site Request Forgery (CSRF), des attaques où un site malveillant trompe votre navigateur pour qu'il effectue des requêtes authentifiées vers votre site WordPress à votre insu.

Configuration recommandée pour des cookies sécurisés

Pour les cookies d'authentification et de session, la configuration recommandée est :

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

Chaque indicateur couvre un vecteur d'attaque différent :

• Secure : empêche l'interception au niveau du réseau
• HttpOnly : empêche le vol au niveau des scripts (XSS)
• SameSite : empêche les abus inter-origines (CSRF)

S'il en manque un, il reste une brèche. Ils fonctionnent en équipe.

Sécurité des cookies tiers et RGPD

Les cookies définis par des services externes chargés sur votre site (analyses, widgets de chat, pixels publicitaires) échappent à votre contrôle direct. Leurs indicateurs de sécurité sont déterminés par le service qui les définit. Mais vous devriez en être conscient. Un cookie tiers sans Secure ou avec SameSite=None crée une exposition sur votre domaine, même si vous n'avez pas défini le cookie vous-même.

Cela est particulièrement pertinent pour la conformité au RGPD : connaître les cookies définis sur votre site et leur configuration fait partie de votre responsabilité en tant qu'exploitant du site.

Auditez les indicateurs de sécurité de vos cookies avec InspectWP

InspectWP examine chaque cookie défini lors du chargement d'une page sur votre site WordPress et signale ceux qui ne possèdent pas les attributs Secure, HttpOnly ou SameSite. Le rapport affiche chaque cookie avec ses indicateurs actuels, afin que vous puissiez voir rapidement lesquels nécessitent votre attention, qu'ils proviennent du noyau WordPress, d'extensions ou de scripts tiers.