Secure Cookie Flag.

The Secure attribute on a Set-Cookie header restricts a cookie to encrypted connections: the browser will never transmit it over plain HTTP, closing the classic interception path where an on-path attacker sniffs a session cookie or forces a victim to an http:// sub-resource to leak it. Historically this enabled "sidejacking" — the 2010 Firesheep Firefox extension trivially hijacked Facebook and Twitter sessions on open Wi-Fi precisely because those cookies lacked Secure, which pushed the industry to full-site HTTPS.

Secure alone is not enough: an attacker who can inject over HTTP can still overwrite a secure cookie (a "cookie tossing" / fixation attack). RFC 6265bis therefore defines two hardening prefixes. A cookie named __Secure-* must carry Secure and be set from an HTTPS origin; a __Host-* cookie must additionally omit Domain and set Path=/, pinning it to the exact host and blocking subdomain-based injection. Browsers silently reject any prefixed cookie that violates these rules. Combine Secure with HttpOnly, SameSite, tight scope, and site-wide HSTS. Note that PortSwigger's 2025 "Cookie Chaos" research showed parser quirks can still bypass prefix enforcement in some stacks — defence in depth remains essential.

flowchart TD
  A[Server sets cookie] --> B{Secure attribute?}
  B -->|No| C[Sent over HTTP + HTTPS<br/>sniffable on the wire]
  B -->|Yes| D{Request scheme?}
  D -->|https://| E[Cookie sent]
  D -->|http://| F[Cookie withheld]
  E --> G{Name prefix?}
  G -->|__Host-| H[Requires Secure, no Domain,<br/>Path=/ - host-pinned]
  G -->|__Secure-| I[Requires Secure +<br/>HTTPS origin]
  G -->|none| J[Overwritable via<br/>HTTP injection]