Secure ist nicht genug: Wie weit reicht Ihr Session-Cookie?

Ein Session-Cookie trägt Secure, HttpOnly und SameSite=Lax. Im Security-Review sieht das erst einmal ordentlich aus.

Dann fällt auf, dass zusätzlich Domain=example.com gesetzt ist.

Plötzlich gehört die Sitzung technisch nicht nur app.example.com. Der Browser darf das Cookie auch an passende Subdomains senden. Vielleicht liegen dort Marketing, Support, alte Kampagnen, ein Kunden-WordPress oder Dienste eines externen Anbieters. Aus einer kleinen Konfigurationsentscheidung wird eine deutlich größere Vertrauenszone.

Die bessere Audit-Frage lautet deshalb nicht nur: Hat das Session-Cookie die üblichen Flags? Sondern: Wie weit darf dieses Cookie tatsächlich reisen — und ist diese Reichweite fachlich notwendig?

Cookie-Sicherheit ist eine Kombination von Grenzen

Die Attribute eines Cookies lösen unterschiedliche Probleme. Sie sind nicht austauschbar.

Secure beschränkt die Übertragung auf sichere Verbindungen. HttpOnly verhindert, dass das Cookie über gewöhnliche JavaScript-Cookie-APIs ausgelesen wird. SameSite steuert, in welchen Cross-Site-Kontexten der Browser das Cookie mitsendet. Domain und Path bestimmen dagegen, für welche Hosts und Pfade es überhaupt in Frage kommt.

Genau deshalb ist ein Cookie nicht automatisch gut abgesichert, nur weil drei bekannte Flags vorhanden sind.

Ein typisches Beispiel:

Set-Cookie: session=...; Domain=example.com; Path=/; Secure; HttpOnly; SameSite=Lax

Das Cookie ist verschlüsselt transportiert und für JavaScript verborgen. Sein Host-Scope ist trotzdem breiter als bei einem host-only Cookie ohne Domain.

1. Domain entscheidet über Ihre Vertrauenszone

Der aktuelle IETF-Entwurf zur Cookie-Spezifikation beschreibt das Verhalten klar: Wird Domain=site.example gesetzt, gilt das Cookie für diese Domain und passende Subdomains. Fehlt das Domain-Attribut, bleibt es auf den Host beschränkt, der es gesetzt hat.

Für eine Anwendung auf app.example.com ist deshalb eine wichtige Frage:

Muss wirklich irgendeine andere Subdomain dieselbe Sitzung erhalten?

Oft lautet die Antwort nein.

Breite Domain-Cookies entstehen trotzdem aus Bequemlichkeit:

• Frontend und API wurden irgendwann auf verschiedene Subdomains verteilt.
• Ein altes SSO-Setup erwartete gemeinsame Cookies.
• Ein Framework-Beispiel wurde übernommen.
• Staging, Admin und App sollten kurzfristig denselben Login teilen.
• Niemand hat die Einstellung nach einem Infrastrukturumbau wieder eingegrenzt.

Das Problem ist organisatorisch: Jede zusätzliche Subdomain wird Teil des Sicherheitsmodells. Eine vergessene Microsite, ein veraltetes CMS oder ein falsch konfigurierter externer Dienst kann plötzlich relevanter werden, als sein Geschäftswert vermuten lässt.

Der IETF-Entwurf weist ausdrücklich darauf hin, dass Cookies keine Integritätsgarantie zwischen Geschwister-Subdomains liefern: Eine Subdomain kann unter passenden Bedingungen ein Cookie für die übergeordnete Domain setzen. Genau diese Art von unnötiger Kopplung sollte ein Audit sichtbar machen.

2. Path ist Routing, keine harte Sicherheitsgrenze

Es klingt verlockend, sensible Cookies einfach mit Path=/admin oder Path=/account einzuschränken.

Das reduziert, bei welchen Requests der Browser das Cookie sendet. Es ist aber keine belastbare Isolation zwischen Anwendungen auf demselben Host. Sowohl die aktuelle IETF-Arbeit als auch MDN warnen davor, Path als Sicherheitsmechanismus zu behandeln.

Wenn zwei Anwendungen wirklich unterschiedliche Vertrauensniveaus haben, ist ein eigener Host meist die deutlich sauberere Grenze als zwei Pfade unter derselben Origin.

Path ist also nützlich, aber es sollte nicht die Aufgabe übernehmen, die eigentlich Host-Trennung, Autorisierung oder eine saubere Session-Architektur leisten muss.

3. SameSite muss zum echten Login-Flow passen

SameSite kennt Strict, Lax und None. Je restriktiver die Einstellung, desto weniger Cross-Site-Kontexte erhalten das Cookie.

Das klingt nach „Strict ist immer besser“, ist aber für reale Produkte zu simpel.

Ein Login kann über einen externen Identity Provider zurückkehren. Nutzer können aus einer E-Mail, einem Zahlungsanbieter oder einem Partnerportal zurück in die Anwendung navigieren. Eingebettete Anwendungen haben wiederum andere Anforderungen. Eine zu strenge Einstellung kann legitime Abläufe beschädigen; eine unnötig offene Einstellung vergrößert die Angriffsfläche.

Darum sollte SameSite bewusst gewählt und getestet werden:

• Funktioniert normaler Login?
• Funktioniert OAuth/OIDC-Rückkehr?
• Funktionieren Magic Links und Passwort-Reset-Links?
• Funktionieren Zahlungs- oder Buchungs-Rückleitungen?
• Wird ein Cross-Site-POST benötigt?
• Gibt es eingebettete Kontexte, die wirklich Cookies brauchen?

SameSite=None ist kein allgemeiner „Kompatibilitätsmodus“. In modernen Browsern wird es zusammen mit Secure verwendet und sollte nur dort eingesetzt werden, wo der Cross-Site-Kontext tatsächlich erforderlich ist.

Und wichtig: SameSite ist eine zusätzliche Schutzschicht gegen bestimmte Cross-Site-Angriffe. Es ersetzt keine serverseitige Autorisierung und nicht automatisch ein vollständiges CSRF-Konzept für jede Anwendung.

4. HttpOnly schützt den Wert — nicht jede Aktion

HttpOnly ist für Session-Identifier sehr sinnvoll, weil Browser das Cookie dann nicht über normale JavaScript-Cookie-APIs bereitstellen.

Aber daraus folgt nicht, dass XSS plötzlich harmlos wäre.

Wenn fremder JavaScript-Code im Kontext Ihrer Anwendung läuft, kann er zwar ein HttpOnly-Session-Cookie nicht einfach aus document.cookie herauskopieren. Er kann jedoch weiterhin Aktionen im Kontext der betroffenen Seite auslösen, Requests anstoßen oder sichtbare Daten manipulieren, solange die Anwendung das zulässt.

HttpOnly reduziert also einen wichtigen Diebstahlpfad. Es ist keine Ersatzlösung für XSS-Prävention, Content Security Policy, Eingabe-/Ausgabesicherheit oder serverseitige Berechtigungsprüfung.

5. __Host- macht eine wichtige Absicht browserprüfbar

Cookie-Präfixe sind interessant, weil sie nicht nur dokumentieren, was Entwickler beabsichtigen. Unterstützende Browser prüfen bestimmte Bedingungen beim Setzen.

Für einen Cookie-Namen mit __Host- gelten drei zentrale Anforderungen:

• Secure muss gesetzt sein.
• Path muss / sein.
• Ein Domain-Attribut darf nicht vorhanden sein.

Damit wird das Cookie host-only und kann nicht einfach als Domain-Cookie über Geschwister-Subdomains geteilt werden.

Für eine klassische First-Party-Webanwendung ist ein Cookie wie __Host-session deshalb ein sehr guter Prüfpunkt: Wenn die Sitzung nur auf diesem Host gebraucht wird, warum lässt die Konfiguration überhaupt eine größere Reichweite zu?

Das schwächere Präfix __Secure- erzwingt Secure, erlaubt aber weiterhin ein Domain-Attribut.

Aktuelle IETF-Arbeit und MDN dokumentieren zusätzlich neuere Präfixe wie __Http- und __Host-Http-, die auch HttpOnly in die Präfix-Anforderungen einbeziehen. Solche neuen Mechanismen sind interessant, sollten aber nicht zur einzigen Schutzschicht werden: Browser-Unterstützung und tatsächliche Client-Matrix gehören weiterhin in den Test.

Sechs Red Flags, die ein Cookie-Audit finden sollte

1. Session-Cookies verwenden pauschal Domain=example.com

Wenn nur app.example.com die Sitzung braucht, ist die zusätzliche Reichweite eine unnötige Vertrauensausweitung.

2. Marketing-, CMS- und App-Subdomains teilen dieselbe Cookie-Domain

Technisch unabhängige Systeme mit sehr unterschiedlichem Wartungsniveau sollten nicht versehentlich im selben Session-Modell landen.

3. SameSite=None wurde gesetzt, „damit es überall funktioniert“

Das ist oft ein Hinweis darauf, dass ein konkreter Cross-Site-Flow nie sauber modelliert wurde.

4. Path wird als Schutz zwischen Admin und öffentlicher Anwendung verkauft

Ein Pfad kann die Senderegel einschränken, ersetzt aber keine belastbare Sicherheitsgrenze.

5. Login setzt ein neues Cookie, Logout entfernt ein anderes

Beim Löschen müssen Scope und Cookie-Identität zur gesetzten Variante passen. Alte Domain- oder Path-Varianten können sonst erhalten bleiben und Debugging in ein kleines Geisterhaus verwandeln.

6. Niemand kann erklären, welches Cookie die Authentifizierung tatsächlich steuert

Frameworks, Reverse Proxies, Auth-SDKs und eigene APIs erzeugen schnell mehrere ähnlich benannte Cookies. Ohne Inventar ist kaum klar, welches davon sicherheitskritisch ist.

Ein praktischer 20-Minuten-Test

Öffnen Sie die Anwendung in einem frischen Browserprofil und beobachten Sie die Cookies vor Login, nach Login und nach Logout.

Dokumentieren Sie für jedes Auth-Cookie:

• Name
• ausstellender Host
• Domain
• Path
• Secure
• HttpOnly
• SameSite
• Ablaufzeit oder Session-Verhalten
• ob ein Präfix verwendet wird
• welche Komponente es setzt
• wofür der Server es akzeptiert

Danach testen Sie bewusst die Grenzen:

1. Öffnen Sie eine Geschwister-Subdomain und prüfen Sie, welche Cookies dort mitgesendet werden.
2. Testen Sie Login und Logout über alle realen Hosts.
3. Testen Sie OAuth, Magic Links, Passwort-Reset und externe Rückleitungen.
4. Prüfen Sie, ob Logout die relevante Sitzung wirklich ungültig macht — nicht nur das sichtbare Cookie entfernt.
5. Wiederholen Sie den Test in den Browsern, die Ihre Nutzer tatsächlich verwenden.
6. Kontrollieren Sie die echten Set-Cookie-Header in Produktion. Framework-Konfiguration und ausgelieferter Header sind nicht dasselbe.

Was Website-Pflichtencheck prüfen würde

Ein Session-Cookie-Review betrachtet nicht nur eine Checkbox-Liste im DevTools-Panel. Relevant ist die gesamte Vertrauensgrenze:

• Welche Hosts teilen Authentifizierung?
• Welche Cookies werden vor und nach Login gesetzt?
• Ist Domain wirklich nötig?
• Passen SameSite und reale Cross-Site-Flows zusammen?
• Werden Secure und HttpOnly konsequent gesetzt?
• Sind __Host- oder andere Präfixe sinnvoll einsetzbar?
• Existieren alte oder doppelte Cookie-Varianten?
• Funktioniert Logout serverseitig?
• Können Marketing-, CMS-, Staging- oder Fremdsysteme den Session-Scope beeinflussen?
• Sind CSRF- und XSS-Schutz unabhängig von Cookie-Flags belastbar?

Der größte Gewinn eines solchen Audits ist oft kein exotischer Browser-Trick. Es ist eine kleinere Vertrauenszone.

Ein Session-Cookie sollte nicht weiter reichen, nur weil es technisch kann. Es sollte genau so weit reichen, wie die Anwendung es wirklich braucht.