Skip to content

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-?

Quellen

Erhalte 100 Cybersecurity-Interviewfragen + Antworten

Gib deine E-Mail-Adresse ein und wir senden dir das kostenlose PDF-Paket und das Flashcard-Deck.

Kein Spam. Jederzeit abbestellbar.