Drapeau de cookie Secure.

L'attribut Secure dans un en-tête Set-Cookie restreint un cookie aux connexions chiffrées : le navigateur ne le transmettra jamais en HTTP non chiffré, fermant la voie d'interception classique où un attaquant sur le chemin renifle un cookie de session ou force une victime vers une sous-ressource http:// pour le faire fuir. Historiquement, cela rendait possible le « sidejacking » — en 2010, l'extension Firefox Firesheep détournait trivialement des sessions Facebook et Twitter sur des réseaux Wi-Fi ouverts, précisément parce que ces cookies n'avaient pas l'attribut Secure, ce qui a poussé l'industrie vers le HTTPS sur l'intégralité des sites.

Secure seul ne suffit pas : un attaquant capable d'injecter en HTTP peut toujours écraser un cookie sécurisé (attaque de « cookie tossing » / fixation). La RFC 6265bis définit donc deux préfixes de durcissement. Un cookie nommé __Secure-* doit porter Secure et être posé depuis une origine HTTPS ; un cookie __Host-* doit en plus omettre Domain et définir Path=/, l'épinglant à l'hôte exact et bloquant l'injection depuis un sous-domaine. Les navigateurs rejettent silencieusement tout cookie préfixé qui enfreint ces règles. Combinez Secure avec HttpOnly, SameSite, un périmètre restreint et HSTS sur l'ensemble du site. À noter : les recherches « Cookie Chaos » de PortSwigger en 2025 ont montré que des bizarreries d'analyseurs peuvent encore contourner l'enforcement des préfixes dans certaines stacks — la défense en profondeur reste essentielle.

flowchart TD
  A[Le serveur pose un cookie] --> B{Attribut Secure ?}
  B -->|Non| C[Envoyé en HTTP + HTTPS<br/>reniflable sur le réseau]
  B -->|Oui| D{Schéma de la requête ?}
  D -->|https://| E[Cookie envoyé]
  D -->|http://| F[Cookie retenu]
  E --> G{Préfixe du nom ?}
  G -->|__Host-| H[Exige Secure, sans Domain,<br/>Path=/ - épinglé à l'hôte]
  G -->|__Secure-| I[Exige Secure +<br/>origine HTTPS]
  G -->|aucun| J[Écrasable via<br/>injection HTTP]