Les cookies HttpOnly sont des cookies qui ne sont pas accessibles au JavaScript côté client, ce qui offre une protection contre les attaques XSS visant à voler des jetons de session. Cet attribut garantit que même si un pirate parvient à exécuter des scripts malveillants, il ne peut pas accéder directement à ces cookies. Il s'agit d'une mesure de sécurité cruciale pour la gestion des sessions et l'authentification.
Un cookie HttpOnly est un cookie que le serveur marque avec l'attribut HttpOnly dans son en-tête Set-Cookie. Ce seul drapeau indique au navigateur de tenir le cookie hors de portée des scripts côté client : il reste attaché automatiquement aux requêtes HTTP correspondantes, de sorte que l'application fonctionne normalement, mais le JavaScript exécuté sur la page ne peut ni le lire ni l'écrire via document.cookie ou l'API Cookie Store. L'attribut vise précisément les cookies de session et d'authentification, ceux qu'un attaquant convoite le plus. Il ne change pas la manière dont le cookie est transmis ou cadré ; c'est le rôle des attributs distincts Secure, SameSite, Domain et Path.
La façon la plus directe d'exploiter une faille de cross-site scripting consiste à lire le cookie de session de la victime et à l'expédier vers un serveur contrôlé par l'attaquant, ce qui lui permet de rejouer la session et d'usurper l'identité de l'utilisateur. HttpOnly supprime cette primitive : même du code qui s'exécute avec succès sur la page ne peut voir la valeur du cookie, et ne peut donc pas l'exfiltrer par de simples lectures. Cela relève sensiblement la barre pour le détournement de session. Il importe toutefois d'être précis quant à la limite : HttpOnly empêche de lire le cookie, pas de l'utiliser. Un script injecté peut toujours émettre des requêtes authentifiées dans le navigateur, en profitant du cookie que le navigateur attache automatiquement.
Définissez HttpOnly sur chaque cookie que le JavaScript n'a aucune raison légitime de toucher, en particulier les jetons de session et d'authentification, et associez-le à Secure et à une valeur SameSite appropriée. Ne le considérez pas comme un contrôle anti-XSS en soi : le vrai remède contre l'injection est le traitement des entrées, l'encodage des sorties et une Content Security Policy solide. HttpOnly limite les dégâts en cas d'échec de ces mesures. Parce qu'une charge utile injectée peut toujours agir au sein de la session sans jamais lire le cookie, détecter le script malveillant lui-même est essentiel. cside analyse les charges utiles des scripts third-party via un méthode Script et peut bloquer les comportements anormaux en temps réel, comblant ainsi la brèche que laissent les drapeaux de cookie.
Non. HttpOnly empêche un script de lire le cookie, mais le script injecté s'exécute tout de même avec les privilèges de l'utilisateur et peut envoyer des requêtes authentifiées, modifier la page, capturer les frappes clavier ou dérober les données des formulaires. HttpOnly réduit l'une des conséquences du XSS ; il n'empêche ni la vulnérabilité ni ses autres exploitations.
Définissez-le sur tout cookie dont le JavaScript n'a pas besoin, ce qui couvre la plupart des cookies de session et d'authentification. L'exception est un cookie que votre propre code côté client doit lire, par exemple certains schémas de jeton CSRF ou d'état d'interface. Pour ceux-là, gardez la valeur non sensible et appuyez-vous sur d'autres protections plutôt que de renoncer à HttpOnly sur le cookie de session.
We answer client-side security questions every day. Bring yours.