Flag de cookie Secure.

El atributo Secure en una cabecera Set-Cookie restringe la cookie a conexiones cifradas: el navegador nunca la transmite por HTTP sin cifrar, cerrando la clásica vía de interceptación en la que un atacante en la ruta husmea una cookie de sesión o fuerza a la víctima hacia un subrecurso http:// para filtrarla. Históricamente esto habilitó el «sidejacking»: en 2010, la extensión de Firefox Firesheep secuestraba de forma trivial sesiones de Facebook y Twitter en redes Wi-Fi abiertas precisamente porque esas cookies carecían de Secure, lo que empujó a la industria hacia el HTTPS en todo el sitio.

Secure por sí solo no basta: un atacante capaz de inyectar sobre HTTP todavía puede sobrescribir una cookie segura (un ataque de «cookie tossing» o fijación). Por ello, RFC 6265bis define dos prefijos de endurecimiento. Una cookie con nombre __Secure-* debe llevar Secure y establecerse desde un origen HTTPS; una cookie __Host-* debe además omitir Domain y fijar Path=/, anclándola al host exacto y bloqueando la inyección desde subdominios. Los navegadores rechazan de forma silenciosa cualquier cookie con prefijo que infrinja estas reglas. Combina Secure con HttpOnly, SameSite, un ámbito ajustado y HSTS en todo el sitio. Ten en cuenta que la investigación «Cookie Chaos» de PortSwigger en 2025 demostró que ciertas peculiaridades del analizador aún pueden eludir la aplicación de prefijos en algunas plataformas: la defensa en profundidad sigue siendo esencial.

flowchart TD
  A[El servidor establece la cookie] --> B{Atributo Secure?}
  B -->|No| C[Enviada por HTTP + HTTPS<br/>husmeable en la red]
  B -->|Si| D{Esquema de la peticion?}
  D -->|https://| E[Cookie enviada]
  D -->|http://| F[Cookie retenida]
  E --> G{Prefijo del nombre?}
  G -->|__Host-| H[Requiere Secure, sin Domain,<br/>Path=/ - anclada al host]
  G -->|__Secure-| I[Requiere Secure +<br/>origen HTTPS]
  G -->|ninguno| J[Sobrescribible mediante<br/>inyeccion HTTP]