Cookie-Sicherheit prüfen: Secure, HttpOnly, SameSite und Cookie-Präfixe

Wenn sich jemand auf Ihrer Website anmeldet, übergibt der Server dem Browser in der Regel ein Session-Cookie. Von da an gilt: Wer dieses Cookie besitzt, ist dieser Nutzer. Die Cookie-Attribute legen fest, wann der Browser es sendet, über welche Verbindungen und ob Skripte auf der Seite es lesen können. Sie richtig zu setzen kostet eine Zeile Konfiguration. Sie falsch zu setzen kann aus einem kleinen Fehler eine Kontoübernahme machen.

Die Attribute, auf die es ankommt

Secure

Secure weist den Browser an, das Cookie nur über HTTPS zu senden. Ohne dieses Attribut kann das Cookie in einer unverschlüsselten HTTP-Anfrage mitreisen – etwa wenn jemand Ihre Domain ohne https:// eintippt und die Weiterleitung noch nicht erfolgt ist. Dort kann es jeder im selben Netzwerk mitlesen. Auf einer HTTPS-Website sollte jedes Cookie Secure sein.

HttpOnly

HttpOnly verbirgt das Cookie vor JavaScript (document.cookie). Gelingt es einem Angreifer, ein Skript in Ihre Seite einzuschleusen, kann er ein Session-Cookie nicht einfach auslesen und anderswohin schicken. Verwenden Sie das Attribut für Session- und Authentifizierungs-Cookies. Cookies, die Ihr eigener Frontend-Code lesen muss – etwa ein CSRF-Token, das manche Frameworks absichtlich für JavaScript zugänglich machen –, können nicht HttpOnly sein. Das ist so vorgesehen.

SameSite

SameSite steuert, ob das Cookie mitgesendet wird, wenn eine Anfrage von einer anderen Website ausgeht:

• SameSite=Strict: wird nur bei Anfragen gesendet, die von Ihrer eigenen Website ausgehen. Am sichersten, aber wer über einen Link aus einer E-Mail auf Ihre Website kommt, erscheint dort zunächst als abgemeldet.
• SameSite=Lax: wird bei Top-Level-Navigationen wie dem Klick auf einen Link gesendet, nicht aber bei websiteübergreifenden Formular-POSTs, Bildern oder Frames. Ein guter Standard für Session-Cookies.
• SameSite=None: wird in jedem websiteübergreifenden Kontext gesendet. Nötig für eingebettete Widgets und manche Single-Sign-on-Abläufe. Es muss mit Secure kombiniert werden, sonst lehnen Browser das Cookie ab.

Chromium-basierte Browser behandeln ein Cookie ohne SameSite-Attribut wie Lax, doch nicht jeder Browser verhält sich gleich. Setzen Sie das Attribut deshalb ausdrücklich.

Domain und Path

Lassen Sie Domain weg, ist das Cookie host-only: Es wird nur an genau den Host gesendet, der es gesetzt hat. Mit Domain=example.com teilen Sie es mit jeder Subdomain – auch mit vergessenen bei einem anderen Hoster, die womöglich schlechter abgesichert sind. Erweitern Sie den Geltungsbereich nur, wenn Sie einen Login wirklich über Subdomains hinweg teilen müssen.

Expires und Max-Age

Ohne Expires oder Max-Age soll ein Cookie nur für die Dauer der Browsersitzung bestehen. Browser, die Sitzungen wiederherstellen, können es allerdings länger behalten. Wählen Sie für dauerhafte Logins eine Lebensdauer, die zum Risiko passt, und sorgen Sie dafür, dass auch der Server Sitzungen auf seiner Seite ablaufen lässt.

Cookie-Präfixe: __Host- und __Secure-

Mit Präfixen im Cookie-Namen setzt der Browser Regeln für Sie durch. Ein Cookie, dessen Name mit __Secure- beginnt, wird nur akzeptiert, wenn es das Attribut Secure trägt und über HTTPS gesetzt wurde. Ein Cookie, das mit __Host- beginnt, ist strenger: Es muss Secure sein, über HTTPS gesetzt werden, Path=/ haben und darf kein Domain-Attribut tragen. Damit ist es an einen einzigen Host gebunden, und eine kompromittierte oder nachlässig gepflegte Subdomain kann es nicht überschreiben.

Für ein Session-Cookie, das nicht über Subdomains hinweg geteilt werden muss, ist __Host- die stärkste verfügbare Option: Set-Cookie: __Host-session=…; Secure; HttpOnly; SameSite=Lax; Path=/.

So prüfen Sie Ihre Cookies

1. Im Browser. Öffnen Sie die Entwicklertools, wechseln Sie zu „Application“ (Chrome, Edge) oder „Web-Speicher“ (Firefox), dann zu „Cookies“, und wählen Sie Ihre Website aus. Die Tabelle zeigt für jedes Cookie die Spalten Domain, Path, Expires, HttpOnly, Secure und SameSite.
2. In der Rohantwort. Klicken Sie im Netzwerk-Tab auf die Anfrage für das Dokument und lesen Sie die Set-Cookie-Antwort-Header. Dort sehen Sie genau, was der Server gesendet hat, einschließlich der Attribute, die der Browser möglicherweise abgelehnt hat.
3. Nach dem Login. Viele Websites setzen ihre wichtigen Cookies erst nach der Anmeldung oder beim Anlegen eines Warenkorbs. Prüfen Sie diese Seiten also noch einmal.
4. Mit einem Checker. Der kostenlose Security-Checker von Rudra liest die Set-Cookie-Header in der Antwort der Seite selbst und meldet Cookies ohne Secure auf HTTPS, sitzungsähnliche Cookies ohne HttpOnly, SameSite=None ohne Secure, Cookies ohne SameSite und Cookies, deren Geltungsbereich auf eine übergeordnete Domain erweitert ist.

Zwei Grenzen der automatischen Prüfung sollten Sie kennen. Ob ein Cookie „sitzungsähnlich“ ist, beurteilt sie anhand seines Namens (Namen, die etwa sess, sid, token oder auth enthalten). Diese Befunde meldet sie daher mit mittlerer Konfidenz: Vergewissern Sie sich, was das Cookie tatsächlich enthält. Außerdem sieht sie nur Cookies, die von dieser einen Antwort gesetzt werden – nicht solche, die später per JavaScript, von anderen Seiten, nach dem Login oder von Drittanbietern gesetzt werden. Cookie-Werte werden niemals gelesen oder gespeichert.

Cookie-Flags auf gängigen Plattformen setzen

• PHP-Sessions: Setzen Sie in der php.ini die Werte session.cookie_secure = 1, session.cookie_httponly = 1 und session.cookie_samesite = "Lax" (ab PHP 7.3) oder übergeben Sie dieselben Optionen an session_set_cookie_params().
• Django: SESSION_COOKIE_SECURE = True und CSRF_COOKIE_SECURE = True. SESSION_COOKIE_HTTPONLY und SESSION_COOKIE_SAMESITE = "Lax" sind bereits die Standardwerte.
• Express (Node.js): res.cookie("sid", value, { secure: true, httpOnly: true, sameSite: "lax" }) oder die cookie-Optionen von express-session. Aktivieren Sie hinter einem Proxy trust proxy, damit Express weiß, dass die Verbindung über HTTPS läuft.
• WordPress: Die Login-Cookies des Core sind HttpOnly und werden als Secure markiert, wenn die Website über HTTPS läuft. Bei Plugin-Cookies ist das unterschiedlich. Prüfen Sie sie in den Entwicklertools und wenden Sie sich an die Plugin-Autoren, wenn Flags fehlen.
• Reverse-Proxy als letzter Ausweg: proxy_cookie_flags von nginx (ab 1.19.3) kann Cookies einer Anwendung, die Sie nicht ändern können, um secure, httponly und samesite ergänzen.

Häufige Fehler

• Cookies in der Produktion als Secure zu markieren, lokal aber nur über HTTP zu testen und das Flag dann „vorübergehend“ abzuschalten.
• SameSite=None ohne Secure zu setzen, sodass Browser das Cookie verwerfen und ein Login oder eine Einbettung nicht mehr funktioniert.
• Session-Cookies „sicherheitshalber“ für die übergeordnete Domain gelten zu lassen.
• Session-Tokens im localStorage abzulegen, wo jedes eingeschleuste Skript sie lesen kann – HttpOnly-Cookies sind sicherer.
• Personenbezogene Daten in Cookie-Werte zu schreiben. Cookies sollten Kennungen enthalten, keine Informationen.

Cookies sind nur ein Teil des Ganzen. Mehr zu Headern, HTTPS und den Grenzen passiver Tests lesen Sie unter Website-Sicherheit prüfen.