Sichere Cookie-Konfiguration: Schutz gegen Session-Hijacking und CSRF

Cookies sind das Rückgrat der Session-Verwaltung — und ein bevorzugtes Angriffsziel. Drei Flags entscheiden, ob Ihre Sessions sicher sind oder kompromittierbar: Secure, HttpOnly und SameSite.

Cookie-Sicherheit prüfen Plattform entdecken
Web Security · 15 Punkte
Von Wolf-Agents Security Team · Aktualisiert: 26. März 2026
Web Security · Grundlagen

Warum Cookie-Sicherheit geschäftskritisch ist

Sichere Cookie-Konfiguration mit Secure, HttpOnly und SameSite verhindert Session-Hijacking, Cookie-Diebstahl per XSS und Cross-Site Request Forgery — drei der häufigsten Angriffe auf Webanwendungen. Cookies speichern die sensibelsten Daten Ihrer Webanwendung: Session-IDs, Authentifizierungs-Tokens und Nutzerpräferenzen. Ein unsicheres Cookie reicht aus, damit ein Angreifer die komplette Session übernimmt — mit allen Rechten des betroffenen Nutzers. Bei E-Commerce-Plattformen bedeutet das: Bestellungen im Namen des Kunden, Zugriff auf Zahlungsdaten und Adressbücher.

Drei HTTP-Attribute entscheiden über die Sicherheit Ihrer Cookies: Secure (verhindert Übertragung über unverschlüsselte Verbindungen), HttpOnly (blockiert JavaScript-Zugriff) und SameSite (schützt gegen Cross-Site Request Forgery). Im Wolf-Agents Web Security Check werden diese drei Flags als Teil der 15 Punkte im Cookie-Bereich bewertet.

€4,88 Mio. Durchschnittliche Kosten eines Datenlecks — Session-Hijacking ist einer der häufigsten initialen Angriffsvektoren IBM Cost of a Data Breach Report 2024
OWASP #7 Cross-Site Request Forgery (CSRF) in den OWASP Top 10 — SameSite-Cookies sind die effektivste Gegenmaßnahme OWASP Top 10 2021: Identification & Authentication Failures
< 5 Min. Implementierungszeit für alle drei Cookie-Flags — der schnellste Security-Gewinn für jede Webanwendung Konfigurationsaufwand pro Stack
Kernkonzepte

Die drei Cookie-Sicherheitsflags

Jedes Flag schützt gegen einen spezifischen Angriffsvektor. Erst die Kombination aller drei macht Ihre Session-Cookies sicher.

Secure

Set-Cookie: session=abc123; Secure

Cookie wird nur über HTTPS übertragen — niemals über unverschlüsseltes HTTP. Ohne Secure kann ein Angreifer im gleichen Netzwerk (z.B. öffentliches WLAN) das Cookie per Man-in-the-Middle-Angriff abfangen.

Verhindert: Man-in-the-Middle

HttpOnly

Set-Cookie: session=abc123; HttpOnly

Cookie ist nicht über JavaScript (document.cookie) zugänglich. Bei XSS-Schwachstellen kann ein Angreifer die Session-ID nicht auslesen und an seinen Server exfiltrieren.

Verhindert: Cookie-Theft per XSS

SameSite

Set-Cookie: session=abc123; SameSite=Strict

Kontrolliert, ob das Cookie bei Cross-Site-Anfragen mitgesendet wird. Strict blockiert alle Cross-Site-Requests, Lax erlaubt Top-Level-GET-Navigation. Schützt gegen CSRF-Angriffe.

Verhindert: Cross-Site Request Forgery

Empfohlene Konfiguration für Session-Cookies

Set-Cookie: __Host-session=abc123; Secure; HttpOnly; SameSite=Strict; Path=/

Der __Host- Prefix erzwingt Secure + Path=/ und verhindert Subdomain-Angriffe — die strengste Cookie-Konfiguration.

Angriffsszenario

CSRF-Angriff: Warum SameSite unverzichtbar ist

Cross-Site Request Forgery (CSRF) nutzt aus, dass Browser Cookies automatisch an die zugehörige Domain senden — unabhängig davon, von welcher Seite der Request kommt. Ein Angreifer kann Ihr eingeloggtes Opfer unbemerkt Aktionen ausführen lassen.

1

Nutzer loggt sich bei Online-Banking ein

Die Bank setzt ein Session-Cookie. Der Nutzer ist authentifiziert und surft weiter.

2

Nutzer öffnet eine manipulierte Website

Über einen Link in einer E-Mail gelangt der Nutzer auf eine Angreifer-Seite — während die Banking-Session noch aktiv ist.

3

Angreifer-Seite sendet versteckten Request

Ein unsichtbares Formular auf der Angreifer-Seite löst einen POST-Request an die Banking-API aus — z.B. eine Überweisung.

Ohne SameSite: Browser sendet Session-Cookie mit. Bank authentifiziert den Request als legitim. Überweisung wird ausgeführt.
Mit SameSite=Strict: Browser blockiert das Cookie bei Cross-Site-Requests. Bank erhält unauthentifizierten Request. Angriff verhindert.

SameSite: Strict vs. Lax — Entscheidungshilfe

Kriterium Strict Lax
Cross-Site-Navigation Cookie wird nicht gesendet Cookie wird gesendet (nur GET)
Externe Links Nutzer muss sich neu einloggen Nahtlose Navigation
CSRF-Schutz Maximum (auch GET geschützt) Gut (POST geschützt)
Empfehlung Banking, Admin-Panels Standard für die meisten Websites
Implementierung

Cookie-Sicherheit in 3 Schritten

Die Implementierung ist unkompliziert — aber die Reihenfolge entscheidet. Konfigurieren Sie zuerst die Flags, dann die Prefixes, dann verifizieren Sie das Ergebnis.

1

Cookie-Flags setzen

Secure + HttpOnly + SameSite für alle Session-Cookies

Konfigurieren Sie die drei Sicherheitsflags direkt in Ihrer Anwendung oder im Webserver. Die Anwendungsebene ist bevorzugt, da Sie dort die volle Kontrolle über jeden einzelnen Cookie haben.

Nginx (proxy_cookie_flags)
# nginx.conf — Cookie-Flags für Upstream-Cookies
location / {
    proxy_pass http://backend;
    proxy_cookie_flags ~ secure httponly samesite=strict;
}
Express (express-session)
// Session-Middleware mit sicheren Cookie-Defaults
app.use(session({
  cookie: {
    secure: process.env.NODE_ENV === 'production',
    httpOnly: true,
    sameSite: 'strict',
  }
}));
2

Cookie-Prefixes nutzen

__Host- oder __Secure- für zusätzlichen Schutz

Cookie-Prefixes sind ein Defense-in-Depth-Mechanismus: Der Browser erzwingt bestimmte Attribute allein aufgrund des Cookie-Namens. __Host- ist die strengste Option — sie verhindert Subdomain-Angriffe und Cookie-Jar-Overflow-Attacken.

__Secure- Secure-Flag erforderlich
__Host- Secure + Path=/ + kein Domain
3

Konfiguration verifizieren

curl und Browser DevTools zur Prüfung

Prüfen Sie nach der Konfiguration, ob alle Flags korrekt gesetzt sind. Öffnen Sie die Browser DevTools → Application → Cookies oder nutzen Sie curl: 

# Cookie-Flags im HTTP-Response prüfen
curl -sI https://ihre-domain.de/login | grep -i set-cookie

# Erwartete Ausgabe:
# Set-Cookie: __Host-session=abc123; Path=/; Secure; HttpOnly; SameSite=Strict
Compliance

Cookie-Sicherheit und regulatorische Anforderungen

Cookie-Flags sind nicht nur technisch sinnvoll — sie sind auch regulatorisch relevant. Drei Rahmenwerke stellen konkrete Anforderungen an die Sicherheit von Session-Cookies.

DSGVO Art. 32

Fordert „geeignete technische Maßnahmen" zum Schutz personenbezogener Daten. Session-Cookies enthalten personenbezogene Identifikatoren — fehlende Flags sind ein dokumentierbarer Mangel bei Datenschutz-Audits. Besonders relevant für E-Commerce und Webanwendungen mit Login.

PCI DSS 4.0.1

Requirement 6.2.4 fordert sichere Softwareentwicklungspraktiken, Requirement 11.6.1 verlangt HTTP-Header-Monitoring. Sichere Cookie-Konfiguration ist ein prüfbarer Nachweis für beide Anforderungen — besonders relevant für alle Unternehmen, die Kreditkartendaten verarbeiten.

NIS2 / BSI

§30 BSIG Maßnahme (e) fordert Systemhärtung nach „Stand der Technik". Cookie-Flags gehören zu den vom BSI empfohlenen Basismaßnahmen (APP.3.1). Wolf-Agents prüft Ihre Cookie-Konfiguration als Teil des Web Security Checks und liefert dokumentierbare Nachweise für NIS2-Audits.

Cookie-Sicherheit für Ihren Stack konfigurieren:

NginxApacheWordPressNext.jsCloudflareExpressCaddyShopifyDemnächst

Wie steht Ihre Domain bei Cookie-Sicherheit?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.

Web Security Check starten Monitoring ab 199 EUR/Mo

Häufig gestellte Fragen

Was sind die drei wichtigsten Cookie-Sicherheitsflags?

Secure (nur HTTPS-Übertragung), HttpOnly (kein JavaScript-Zugriff) und SameSite (CSRF-Schutz). Zusammen verhindern sie Session-Hijacking, Cookie-Diebstahl per XSS und Cross-Site Request Forgery. Alle drei Flags sind kostenlos und in wenigen Minuten konfigurierbar.

Was ist der Unterschied zwischen SameSite=Strict und SameSite=Lax?

SameSite=Strict verhindert das Senden von Cookies bei jeder Cross-Site-Anfrage — auch bei normaler Navigation über einen externen Link. SameSite=Lax erlaubt Cookies bei Top-Level-GET-Navigation (z.B. Klick auf einen Link), blockiert aber Cross-Site-POST-Requests. Für die meisten Websites ist Lax die beste Wahl; für hochsensitive Anwendungen wie Banking empfiehlt sich Strict.

Was bewirkt das HttpOnly-Flag bei Cookies?

HttpOnly verhindert den Zugriff auf ein Cookie über JavaScript (document.cookie). Das schützt Session-Cookies bei XSS-Angriffen: Selbst wenn ein Angreifer JavaScript auf Ihrer Seite ausführen kann, kann er die Session-ID nicht auslesen und an seinen Server senden.

Sind sichere Cookies für die DSGVO-Compliance relevant?

Ja. DSGVO Art. 32 fordert „geeignete technische Maßnahmen" zum Schutz personenbezogener Daten. Session-Cookies enthalten personenbezogene Daten (Session-Identifikatoren). Fehlende Cookie-Flags wie Secure und HttpOnly sind ein dokumentierbarer Mangel, der bei Datenschutz-Audits beanstandet werden kann.

Was sind Cookie-Prefixes wie __Host- und __Secure-?

Cookie-Prefixes sind ein Defense-in-Depth-Mechanismus: __Secure- erzwingt das Secure-Flag, __Host- erzwingt zusätzlich Path=/ und verbietet das Domain-Attribut. Damit werden Subdomain-Angriffe und Path-Manipulation verhindert. Für Session-Cookies empfehlen wir __Host- als strengsten Schutz.

Kann ich Cookie-Sicherheit automatisch prüfen?

Ja. Der Wolf-Agents Web Security Check analysiert Ihre Cookie-Konfiguration automatisch und bewertet Secure, HttpOnly und SameSite als Teil der 166 Prüfpunkte. Sie können auch manuell mit curl (curl -sI https://domain.de/login | grep Set-Cookie) oder den Browser DevTools (Application → Cookies) prüfen.