Quand vous naviguez sur le web, des dizaines de cookies s'échangent en coulisses entre votre navigateur et les sites que vous visitez. La plupart passent inaperçus — mais certains arborent des attributs techniques comme HttpOnly ou SameSite qui font une grande différence en matière de sécurité. Voici ce qu'ils signifient vraiment, et pourquoi vous devriez vous y intéresser.
HttpOnly : le cookie que JavaScript ne peut pas toucher
L'attribut HttpOnly est une instruction donnée au navigateur : "ce cookie ne doit jamais être accessible via JavaScript".
Concrètement, quand un serveur envoie un cookie avec cet attribut, le code JavaScript exécuté sur la page — y compris d'éventuels scripts malveillants injectés — ne peut pas lire sa valeur. Seul le navigateur y accède, uniquement lors des échanges HTTP/HTTPS avec le serveur.
Pourquoi c'est important ?
La principale menace que HttpOnly neutralise s'appelle le XSS (Cross-Site Scripting). Dans une attaque XSS, un pirate parvient à injecter du code JavaScript malveillant dans une page web. Sans HttpOnly, ce script pourrait lire vos cookies de session et les transmettre à l'attaquant — qui prendrait alors le contrôle de votre compte.
Avec HttpOnly activé sur le cookie de session, cette porte est fermée. Le script malveillant ne voit rien.
Exemple concret : lorsque vous vous connectez à votre banque en ligne, le cookie qui maintient votre session active est presque toujours marqué HttpOnly. C'est une bonne pratique devenue standard.
Pour en savoir plus sur la gestion des cookies dans votre navigateur, consultez nos guides pour Chrome ou Firefox.
SameSite : la protection contre les requêtes inter-sites
L'attribut SameSite est plus récent et répond à une autre catégorie d'attaque : le CSRF (Cross-Site Request Forgery), ou falsification de requête inter-sites.
Imaginez que vous êtes connecté à votre webmail et que vous visitez simultanément un site malveillant. Sans protection, ce site pourrait déclencher discrètement une requête vers votre webmail (par exemple, envoyer un email à votre insu) en profitant du fait que votre navigateur envoie automatiquement les cookies associés.
SameSite dit au navigateur quand il a le droit d'envoyer un cookie dans une requête provenant d'un autre site. Il existe trois valeurs :
SameSite=Strict
Le cookie n'est jamais envoyé dans les requêtes inter-sites, même si vous cliquez sur un lien depuis un autre site. C'est le niveau de protection le plus élevé, mais aussi le plus contraignant : si quelqu'un partage un lien vers votre espace client bancaire, vous arriverez déconnecté.
SameSite=Lax
C'est le compromis recommandé et la valeur par défaut dans la plupart des navigateurs modernes. Le cookie est envoyé lors des navigations simples (clic sur un lien), mais pas lors des requêtes automatiques (images, iframes, formulaires POST depuis un autre site). Ça couvre la plupart des cas d'usage sans trop gêner l'expérience utilisateur.
SameSite=None
Le cookie est envoyé dans tous les contextes inter-sites. C'est ce qu'utilisent les cookies tiers pour le suivi publicitaire ou certains widgets embarqués. Depuis 2020, Chrome et les autres navigateurs exigent que ces cookies soient aussi marqués Secure (envoyés uniquement en HTTPS) — ce qui est la moindre des choses.
HttpOnly et SameSite : deux protections complémentaires
Ces deux attributs ne font pas la même chose et se complètent naturellement :
| Attribut | Protège contre | Mécanisme |
|---|---|---|
| HttpOnly | XSS (vol de cookie via JS) | Interdit la lecture par JavaScript |
| SameSite | CSRF (requête forgée) | Contrôle quand le cookie est envoyé |
Un cookie de session bien configuré aura typiquement les deux : HttpOnly; SameSite=Lax; Secure.
L'attribut Secure, en bonus, garantit que le cookie ne circule que sur des connexions HTTPS — une troisième couche de protection évidente mais souvent oubliée.
Comment voir les attributs d'un cookie ?
Vous pouvez inspecter les cookies d'un site directement dans votre navigateur :
- Appuyez sur F12 (ou clic droit > Inspecter)
- Allez dans l'onglet Application (Chrome/Edge) ou Stockage (Firefox)
- Cliquez sur Cookies dans la barre latérale
- Sélectionnez le domaine du site
Vous verrez alors pour chaque cookie ses attributs, y compris HttpOnly et SameSite. Les colonnes correspondantes seront cochées si l'attribut est actif.
Si vous souhaitez aller plus loin dans la gestion de vos cookies, notre page sur la désactivation des cookies et nos infos cookies peuvent vous être utiles.
Ces attributs concernent-ils les utilisateurs ou les développeurs ?
Principalement les développeurs web, qui sont responsables de configurer correctement les cookies de leurs applications. En tant qu'utilisateur, vous ne pouvez pas activer HttpOnly ou SameSite vous-même — c'est le serveur qui les positionne.
En revanche, vous pouvez constater si un site applique ces bonnes pratiques en inspectant ses cookies. Des navigateurs comme Firefox ou Brave ajoutent également leurs propres protections côté client pour limiter les abus.
Mini FAQ
Un cookie HttpOnly peut-il quand même être volé ? HttpOnly protège contre le vol via JavaScript, mais pas contre d'autres vecteurs : un attaquant ayant accès au trafic réseau (connexion non chiffrée) ou à votre machine peut toujours y accéder. C'est pourquoi HttpOnly se combine toujours avec l'attribut Secure (HTTPS obligatoire).
Pourquoi mon navigateur bloque-t-il certains cookies SameSite=None ? Depuis 2020, Chrome (et les autres navigateurs majeurs) refusent les cookies SameSite=None sans l'attribut Secure. Si un site mal configuré envoie un cookie SameSite=None sans HTTPS, le navigateur le rejette silencieusement. Ce comportement est volontaire et protège les utilisateurs.
Est-ce que SameSite=Lax casse les connexions via réseaux sociaux ? Rarement. Les flux OAuth modernes (connexion via Google, Facebook, etc.) sont conçus pour fonctionner avec SameSite=Lax. Si vous rencontrez des problèmes de connexion, consultez notre guide pour Safari ou iPhone qui ont parfois des comportements spécifiques.
HttpOnly et SameSite sont deux petits attributs discrets qui font un travail énorme en arrière-plan. Ils ne sont pas visibles pour l'utilisateur ordinaire, mais leur absence se remarque vite — lors d'une faille de sécurité. La prochaine fois que vous inspecterez les cookies d'un site, regardez si ces attributs sont bien présents sur les cookies de session : c'est un bon indicateur du soin apporté à la sécurité de l'application.