Sichere Cookies: Der vollständige Leitfaden für Ihre Website

Cookies speichern Session-Informationen, Authentifizierungstoken und Benutzereinstellungen. Ein falsch konfiguriertes Cookie kann Session-Hijacking, CSRF-Angriffe und Datenschutzverstöße ermöglichen. Dieser Leitfaden zeigt, wie Sie Cookies korrekt absichern.

Cookie-Sicherheitsattribute im Überblick

Die 5 sicherheitsrelevanten Attribute

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

| Attribut | Wirkung | Standard wenn fehlt | |---|---|---| | HttpOnly | Cookie nicht per JavaScript lesbar | Lesbar (unsicher) | | Secure | Cookie nur über HTTPS gesendet | Auch über HTTP (unsicher) | | SameSite | Cross-Site-Verhalten kontrolliert | Lax (seit Chrome 80) | | Path | Cookie nur für bestimmte Pfade | / (gesamte Domain) | | Max-Age / Expires | Lebensdauer des Cookies | Session-Cookie (bis Browser schließt) |

HttpOnly: Schutz gegen XSS

Was HttpOnly verhindert

Ohne HttpOnly kann JavaScript Cookies auslesen:

// Ohne HttpOnly: Angreifer kann Cookies stehlen
// document.cookie gibt alle nicht-HttpOnly Cookies zurück

Mit HttpOnly ist das Cookie für JavaScript unsichtbar. Selbst bei einer XSS-Schwachstelle kann der Angreifer das Session-Cookie nicht direkt stehlen.

Wann HttpOnly verwenden

| Cookie-Typ | HttpOnly? | Begründung | |---|---|---| | Session-ID | Ja | Kein Grund für JavaScript-Zugriff | | Auth-Token | Ja | Kein Grund für JavaScript-Zugriff | | CSRF-Token | Nein | JavaScript muss das Token lesen können | | Spracheinstellung | Optional | Kann auch Server-seitig gelesen werden | | Benutzereinstellungen | Optional | Abhängig von der Implementierung |

Secure: Nur HTTPS

Warum Secure wichtig ist

Ohne das Secure-Attribut wird das Cookie auch über unverschlüsselte HTTP-Verbindungen gesendet. In einem offenen WLAN (Café, Flughafen) kann ein Angreifer das Cookie mitlesen.

Set-Cookie: session_id=abc123; Secure

Regel: Jede Website sollte ausschließlich HTTPS verwenden. In diesem Fall ist Secure ein Sicherheitsnetz für den Fall, dass ein HTTP-Zugriff dennoch stattfindet.

SameSite: Schutz gegen CSRF

Das SameSite-Attribut kontrolliert, ob Cookies bei Cross-Site-Requests gesendet werden.

Die drei Modi

| Modus | Verhalten | Schutz | |---|---|---| | Strict | Cookie nur bei Same-Site-Requests | Maximaler Schutz, kann UX einschränken | | Lax | Cookie bei Navigation (GET), nicht bei POST | Guter Kompromiss (Standard seit Chrome 80) | | None | Cookie immer gesendet (erfordert Secure!) | Kein CSRF-Schutz, nur für Cross-Site-Nutzung |

Wann welchen Modus verwenden

| Szenario | SameSite | Begründung | |---|---|---| | Session-Cookie | Lax oder Strict | CSRF-Schutz bei State-ändernden Requests | | API-Authentication-Cookie | Strict | Maximaler Schutz für API-Aufrufe | | Eingebetteter Widget-Cookie | None; Secure | Widget muss Cross-Site funktionieren | | Analytics-Cookie (1st Party) | Lax | Funktioniert bei normaler Navigation |

CSRF-Angriff ohne SameSite

Ohne SameSite kann ein Angreifer von einer fremden Website einen Request auslösen, der das Session-Cookie des Opfers enthält:

<!-- Auf evil.com: Löst einen Request an bank.de aus -->
<form action="https://bank.de/ueberweisung" method="POST">
  <input type="hidden" name="empfaenger" value="angreifer" />
  <input type="hidden" name="betrag" value="10000" />
</form>
<script>document.forms[0].submit()</script>

Mit SameSite=Lax oder Strict wird das Session-Cookie bei diesem Request nicht gesendet — der Angriff schlägt fehl.

Cookie-Lebensdauer

Session-Cookie vs. Persistent Cookie

| Typ | Max-Age / Expires | Verhalten | |---|---|---| | Session-Cookie | Nicht gesetzt | Gelöscht wenn Browser geschlossen | | Persistent Cookie | Gesetzt | Überlebt Browser-Neustart |

Empfohlene Lebensdauern

| Cookie-Typ | Max-Age | Begründung | |---|---|---| | Session-ID | 1–24 Stunden | Minimiert Expositionszeitraum | | Remember-Me-Token | 30 Tage | Benutzerfreundlichkeit | | CSRF-Token | Session | Endet mit der Session | | Consent-Cookie | 12 Monate | DSGVO-konformer Zeitraum | | Spracheinstellung | 12 Monate | Benutzerfreundlichkeit |

Cookie-Prefix: Zusätzliche Absicherung

Moderne Browser unterstützen Cookie-Prefixes für zusätzliche Garantien:

__Secure- Prefix

Set-Cookie: __Secure-session=abc123; Secure; Path=/

Der Browser akzeptiert das Cookie nur, wenn es über HTTPS gesetzt wird und das Secure-Attribut hat.

__Host- Prefix (strengster Schutz)

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

Der Browser akzeptiert das Cookie nur, wenn:

Über HTTPS gesetzt
Secure-Attribut vorhanden
Path=/ gesetzt
Kein Domain-Attribut (nur für exakte Domain)

Empfehlung: Verwenden Sie __Host- für Session-Cookies — es ist der stärkste verfügbare Schutz.

Praxisbeispiele

Node.js (Express)

app.use(session({
  cookie: {
    httpOnly: true,
    secure: true,
    sameSite: 'lax',
    maxAge: 3600000, // 1 Stunde
    path: '/',
  },
  name: '__Host-session',
}))

Next.js (Server Action)

import { cookies } from 'next/headers'

cookies().set('session', token, {
  httpOnly: true,
  secure: true,
  sameSite: 'lax',
  maxAge: 3600,
  path: '/',
})

Nginx (Header-Level)

# Vorhandene Cookies nachhärten
proxy_cookie_flags ~ httponly secure samesite=lax;

Cookie-Audit: So prüfen Sie Ihre Cookies

Browser DevTools

Chrome: F12 → Application → Cookies
Prüfen Sie für jedes Cookie: HttpOnly, Secure, SameSite, Ablaufzeit
Markieren Sie unsichere Cookies (fehlende Attribute)

Automatisiert prüfen

| Tool | Funktion | |---|---| | WarDek Scanner | Prüft Cookie-Attribute als Teil des Sicherheitsscans | | OWASP ZAP | Meldet unsichere Cookie-Konfigurationen | | Mozilla Observatory | Bewertet Cookie-Sicherheit |

Häufige Fehler

| Fehler | Risiko | Lösung | |---|---|---| | HttpOnly fehlt bei Session-Cookie | XSS kann Session stehlen | Immer setzen | | Secure fehlt | Cookie über HTTP abfangbar | Immer setzen (HTTPS ist Standard) | | SameSite=None ohne Secure | Browser lehnt Cookie ab | None immer mit Secure kombinieren | | Zu lange Lebensdauer | Gestohlenes Cookie lange nutzbar | Max. 24h für Sessions | | Sensitive Daten im Cookie | Cookie-Inhalt sichtbar | Nur Session-ID im Cookie, Daten serverseitig | | Cookie-Domain zu breit | Subdomains können Cookie lesen | Spezifische Domain setzen |

Checkliste: Cookie-Sicherheit

☐ Session-Cookies: HttpOnly, Secure, SameSite=Lax
☐ Keine sensitiven Daten direkt im Cookie-Wert
☐ Angemessene Lebensdauer (Max-Age)
☐ Cookie-Prefixes verwendet (__Host- oder __Secure-)
☐ CSRF-Token zusätzlich implementiert (bei SameSite=Lax)
☐ Session-Invalidierung bei Logout serverseitig
☐ Regelmäßiger Cookie-Audit (quartalsweise)

Fazit

Cookie-Sicherheit erfordert nur wenige Konfigurationszeilen — aber die Auswirkungen fehlender Attribute sind gravierend. HttpOnly, Secure und SameSite sollten für jedes sicherheitsrelevante Cookie Standard sein. Prüfen Sie Ihre Cookies regelmäßig mit Browser DevTools oder automatisierten Scannern.

Scannen Sie Ihre Website kostenlos mit WarDek — OWASP, NIS2, DSGVO, AI Act Compliance in einem Scan.

Sichere Cookies: Vollständiger Leitfaden