Was bewirken die Cookie-Attribute HttpOnly, Secure und SameSite?
Kurzantwort
HttpOnly verbirgt das Cookie vor JavaScript, sodass XSS es nicht über document.cookie stehlen kann. Secure stellt sicher, dass das Cookie nur über HTTPS gesendet wird, und blockiert das Abfangen im Netzwerk. SameSite steuert, ob das Cookie bei Cross-Site-Anfragen gesendet wird, und mildert CSRF ab. Zusammen härten sie Sitzungs-Cookies gegen die häufigsten Diebstahl- und Missbrauchswege.
Ein Sitzungs-Cookie ist ein Inhaber-Token: Wer es besitzt, ist der Nutzer. Die Attribute, die du ihm gibst, bestimmen also, wie schwer es für einen Angreifer ist, dieses Token zu stehlen, abzufangen oder zu missbrauchen. Drei Attribute erledigen den Großteil der Arbeit, und jedes entspricht einer eigenen Bedrohung.
HttpOnly — blockiert den Skriptzugriff
HttpOnly weist den Browser an, das Cookie nicht für JavaScript verfügbar zu machen. document.cookie kann es nicht lesen. Das ist die zentrale Gegenmaßnahme gegen XSS-basierten Sitzungsdiebstahl: Selbst wenn ein Angreifer Skript einschleust, kann er das Sitzungs-Cookie nicht exfiltrieren. Beachte: Es verhindert XSS nicht selbst — das eingeschleuste Skript kann weiterhin authentifizierte Anfragen als der Nutzer stellen —, aber es hält das Cookie davon ab, den Browser zu verlassen, was den Schaden eindämmt.
Secure — nur HTTPS
Secure weist den Browser an, das Cookie nur über HTTPS zu senden. Ohne das würde eine einzige versehentliche http://-Anfrage (oder eine von einem Angreifer erzwungene) das Sitzungs-Cookie im Klartext übertragen, wo ein Netzwerkangreifer es mitlesen kann. Zusammen mit HSTS schließt das den Weg des Netzwerk-Abfangens.
SameSite — Cross-Site-Senden
SameSite steuert, ob das Cookie bei Anfragen mitgeschickt wird, die von anderen Websites stammen:
- Strict — nie cross-site gesendet (stärkster CSRF-Schutz, kann aber eingehende Links zu authentifizierten Seiten stören).
- Lax — bei Top-Level-Navigationen gesendet, aber nicht bei Cross-Site-Unteranfragen/POSTs; ein guter Standard, der klassisches CSRF blockiert.
- None — immer gesendet, und erfordert
Secure.
Doppelt hält besser: Namenspräfixe
Das Präfix __Host- lässt den Browser erzwingen, dass ein Cookie Secure ist, den Pfad / hat und nicht domänenweit gilt — ein Schutz gegen Subdomain-/Cookie-Fixation-Tricks.
Prüfer achten auf die Zuordnung Attribut zu Bedrohung (HttpOnly/XSS-Diebstahl, Secure/Sniffing, SameSite/CSRF) und auf die Feinheit, dass HttpOnly die Auswirkungen von XSS begrenzt, statt XSS zu verhindern.
Wahrscheinliche Anschlussfragen
- Warum verhindert HttpOnly kein XSS, sondern begrenzt nur dessen Auswirkungen?
- Was ist der Unterschied zwischen SameSite=Lax und SameSite=Strict?
- Was erzwingt das Cookie-Namenspräfix __Host-?