Les cookies sécurisés sont des cookies HTTP dotés d'attributs spéciaux qui renforcent la sécurité. Le drapeau « Secure » garantit que les cookies ne sont envoyés que via des connexions HTTPS, tandis que « HttpOnly » empêche JavaScript l'accès aux cookies, protégeant ainsi contre les attaques XSS. L'attribut « SameSite » aide à prévenir les attaques CSRF en contrôlant la manière dont les cookies sont envoyés dans les requêtes intersites.
Les cookies sécurisés sont des cookies HTTP ordinaires renforcés par des attributs de protection. Le drapeau Secure indique au navigateur de n'envoyer le cookie qu'en HTTPS, jamais en HTTP clair. HttpOnly masque le cookie au JavaScript, de sorte que document.cookie ne peut pas le lire. SameSite (Lax, Strict ou None) contrôle si le cookie est attaché aux requêtes cross-site, ce qui limite son usage dans la falsification de requête cross-site. Un renforcement supplémentaire inclut les cookies host-only ou les préfixes de nom __Host- et __Secure-, un cadrage strict de Path et Domain, et des expirations courtes. Ensemble, ces attributs réduisent comment, quand et par qui un cookie, souvent un identifiant de session, peut être consulté ou rejoué.
Les cookies de session ont une grande valeur : quiconque en détient un peut souvent agir comme l'utilisateur connecté. Chaque attribut ferme une voie de vol précise. Sans Secure, une seule requête en HTTP peut divulguer le cookie à un espion du réseau. Sans HttpOnly, toute charge utile de cross-site scripting réussie peut lire le cookie et l'exfiltrer. Sans SameSite, un site malveillant peut déclencher silencieusement des requêtes authentifiées dans le navigateur de la victime. Aucun de ces attributs ne suffit à lui seul ; un cookie a besoin de la bonne combinaison selon son usage. Bien les régler est l'une des mesures les moins coûteuses et les plus efficaces de la sécurité des sessions web, et une mauvaise configuration est un constat fréquent lors des audits.
Définissez Secure et HttpOnly sur chaque cookie de session et d'authentification, choisissez SameSite=Lax ou Strict à moins qu'un réel besoin cross-site n'impose None (qui exige alors Secure), et privilégiez le préfixe __Host- pour les cookies de session afin de verrouiller le domaine et le chemin. Combinez cela avec du HTTPS partout et HSTS. Les attributs limitent l'exfiltration mais n'empêchent pas l'injection qui dérobe le cookie en premier lieu : une faille de cross-site scripting peut toujours effectuer des actions au sein de la session, même sans lire le cookie. cside détecte et peut bloquer les comportements de script malveillants au niveau de la charge utile, traitant ainsi la voie d'injection que les seuls drapeaux de cookie laissent ouverte.
Non. Secure ne contrôle que le transport : il empêche le navigateur d'envoyer le cookie en HTTP non chiffré. La valeur elle-même n'est ni chiffrée ni signée par le drapeau. Si le contenu est sensible, le serveur doit le chiffrer ou le signer séparément, ou, mieux encore, ne stocker qu'un identifiant de session opaque et imprévisible.
Ils visent des menaces différentes. Secure régit quel transport achemine le cookie, HttpOnly régit si le JavaScript peut le lire, et SameSite régit si le cookie accompagne les requêtes cross-site. SameSite atténue principalement la falsification de requête cross-site, tandis que HttpOnly atténue principalement le vol par cross-site scripting. Des cookies robustes définissent en général les trois.
We answer client-side security questions every day. Bring yours.