Secure-Cookie-Flag.

Das Attribut Secure in einem Set-Cookie-Header beschränkt ein Cookie auf verschlüsselte Verbindungen: Der Browser überträgt es niemals über einfaches HTTP und schliesst damit den klassischen Abfangpfad, bei dem ein On-Path-Angreifer ein Session-Cookie mitschneidet oder ein Opfer auf eine http://-Subressource zwingt, um es abzugreifen. Historisch ermöglichte dies das sogenannte „Sidejacking“ — die Firefox-Erweiterung Firesheep von 2010 kaperte in offenen WLANs mühelos Facebook- und Twitter-Sitzungen, gerade weil diesen Cookies das Secure-Attribut fehlte, was die Branche zu durchgängigem HTTPS drängte.

Secure allein genügt nicht: Ein Angreifer, der über HTTP injizieren kann, vermag ein Secure-Cookie dennoch zu überschreiben (ein „Cookie-Tossing“- bzw. Fixierungsangriff). RFC 6265bis definiert daher zwei härtende Präfixe. Ein Cookie mit dem Namen __Secure-* muss Secure tragen und von einer HTTPS-Origin gesetzt werden; ein __Host-*-Cookie muss zusätzlich Domain weglassen und Path=/ setzen, wodurch es an den exakten Host gebunden wird und Injektion über Subdomains blockiert. Browser lehnen jedes präfigierte Cookie, das diese Regeln verletzt, stillschweigend ab. Kombiniere Secure mit HttpOnly, SameSite, engem Scope und site-weitem HSTS. Beachte, dass PortSwiggers Untersuchung „Cookie Chaos“ von 2025 zeigte, dass Parser-Eigenheiten die Durchsetzung von Präfixen in manchen Stacks weiterhin umgehen können — Defence-in-Depth bleibt unerlässlich.

flowchart TD
  A[Server setzt Cookie] --> B{Secure-Attribut?}
  B -->|Nein| C[Über HTTP + HTTPS gesendet<br/>auf der Leitung mitschneidbar]
  B -->|Ja| D{Schema der Anfrage?}
  D -->|https://| E[Cookie gesendet]
  D -->|http://| F[Cookie zurückgehalten]
  E --> G{Namenspräfix?}
  G -->|__Host-| H[Erfordert Secure, kein Domain,<br/>Path=/ - an Host gebunden]
  G -->|__Secure-| I[Erfordert Secure +<br/>HTTPS-Origin]
  G -->|keins| J[Über HTTP-Injektion<br/>überschreibbar]