Sécurité

Sichere Cookies: Vollständiger Leitfaden

Web-Cookies absichern: HttpOnly, Secure, SameSite, Risiken bei Session-Diebstahl und CSRF, Audit und Best Practices für KMU.

28 mars 20264 min de lectureWarDek Team

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
AttributWirkungStandard wenn fehlt
HttpOnlyCookie nicht per JavaScript lesbarLesbar (unsicher)
SecureCookie nur über HTTPS gesendetAuch über HTTP (unsicher)
SameSiteCross-Site-Verhalten kontrolliertLax (seit Chrome 80)
PathCookie nur für bestimmte Pfade/ (gesamte Domain)
Max-Age / ExpiresLebensdauer des CookiesSession-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-TypHttpOnly?Begründung
Session-IDJaKein Grund für JavaScript-Zugriff
Auth-TokenJaKein Grund für JavaScript-Zugriff
CSRF-TokenNeinJavaScript muss das Token lesen können
SpracheinstellungOptionalKann auch Server-seitig gelesen werden
BenutzereinstellungenOptionalAbhä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

ModusVerhaltenSchutz
StrictCookie nur bei Same-Site-RequestsMaximaler Schutz, kann UX einschränken
LaxCookie bei Navigation (GET), nicht bei POSTGuter Kompromiss (Standard seit Chrome 80)
NoneCookie immer gesendet (erfordert Secure!)Kein CSRF-Schutz, nur für Cross-Site-Nutzung

Wann welchen Modus verwenden

SzenarioSameSiteBegründung
Session-CookieLax oder StrictCSRF-Schutz bei State-ändernden Requests
API-Authentication-CookieStrictMaximaler Schutz für API-Aufrufe
Eingebetteter Widget-CookieNone; SecureWidget muss Cross-Site funktionieren
Analytics-Cookie (1st Party)LaxFunktioniert 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

TypMax-Age / ExpiresVerhalten
Session-CookieNicht gesetztGelöscht wenn Browser geschlossen
Persistent CookieGesetztÜberlebt Browser-Neustart

Empfohlene Lebensdauern

Cookie-TypMax-AgeBegründung
Session-ID1–24 StundenMinimiert Expositionszeitraum
Remember-Me-Token30 TageBenutzerfreundlichkeit
CSRF-TokenSessionEndet mit der Session
Consent-Cookie12 MonateDSGVO-konformer Zeitraum
Spracheinstellung12 MonateBenutzerfreundlichkeit

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

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

Automatisiert prüfen

ToolFunktion
WarDek ScannerPrüft Cookie-Attribute als Teil des Sicherheitsscans
OWASP ZAPMeldet unsichere Cookie-Konfigurationen
Mozilla ObservatoryBewertet Cookie-Sicherheit

Häufige Fehler

FehlerRisikoLösung
HttpOnly fehlt bei Session-CookieXSS kann Session stehlenImmer setzen
Secure fehltCookie über HTTP abfangbarImmer setzen (HTTPS ist Standard)
SameSite=None ohne SecureBrowser lehnt Cookie abNone immer mit Secure kombinieren
Zu lange LebensdauerGestohlenes Cookie lange nutzbarMax. 24h für Sessions
Sensitive Daten im CookieCookie-Inhalt sichtbarNur Session-ID im Cookie, Daten serverseitig
Cookie-Domain zu breitSubdomains können Cookie lesenSpezifische Domain setzen

Checkliste: Cookie-Sicherheit

  1. ☐ Session-Cookies: HttpOnly, Secure, SameSite=Lax
  2. ☐ Keine sensitiven Daten direkt im Cookie-Wert
  3. ☐ Angemessene Lebensdauer (Max-Age)
  4. ☐ Cookie-Prefixes verwendet (__Host- oder __Secure-)
  5. ☐ CSRF-Token zusätzlich implementiert (bei SameSite=Lax)
  6. ☐ Session-Invalidierung bei Logout serverseitig
  7. ☐ 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.

#Cookies#Session-Sicherheit#CSRF#Web-Sicherheit

Scannez votre site gratuitement

WarDek détecte les vulnérabilités mentionnées dans cet article en quelques secondes.