Sichere Cookie-Attribute

Was diese Prüfung macht

Liest jeden Set-Cookie-Response-Header und prüft auf drei Flags:

• Secure — Cookie nur über HTTPS gesendet.
• HttpOnly — Cookie aus JavaScript nicht lesbar (blockiert XSS-getriebenen Diebstahl).
• SameSite=Lax|Strict|None — Verhalten bei seitenübergreifenden Anfragen (blockiert CSRF).

Sie besteht, wenn jedes Cookie, das Authentifizierungs- oder Session-State trägt, alle drei hat.

Warum es zählt

Cookies halten die Schlüssel zu den Sessions deiner Nutzer:innen. Ein Cookie ohne diese Flags ist eine XSS-Schwachstelle oder ein feindliches WLAN entfernt von der Account-Übernahme:

• Kein Secure → Cookie reist über reines HTTP bei der ersten Anfrage, bevor HSTS greift. Im Café-WLAN abhörbar.
• Kein HttpOnly → jedes injizierte Skript (XSS, bösartige npm-Abhängigkeit, feindliche Anzeige) kann das Cookie über document.cookie lesen und exfiltrieren.
• Kein SameSite → Cross-Site Request Forgery (CSRF). Eine bösartige Seite kann Formulare senden oder Anfragen als deine eingeloggte:r Nutzer:in auslösen.

Browser haben ihre Defaults verschärft: Chrome liefert mittlerweile SameSite=Lax als Standard, aber Legacy-Code, der Cookies explizit ohne Flags setzt, leakt weiterhin.

So behebst du es

Setze jedes Session-/Auth-Cookie mit allen drei Flags.

Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=86400

Express / Node.js:

res.cookie("session", token, {
  httpOnly: true,
  secure: true,
  sameSite: "lax",
  maxAge: 86400 * 1000,
  path: "/",
});

Next.js (App Router mit cookies()):

import { cookies } from "next/headers";

cookies().set({
  name: "session",
  value: token,
  httpOnly: true,
  secure: true,
  sameSite: "lax",
  path: "/",
  maxAge: 86400,
});

Bun.serve():

return new Response("ok", {
  headers: {
    "Set-Cookie": `session=${token}; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=86400`,
  },
});

Django:

# settings.py
SESSION_COOKIE_SECURE = True
SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_SAMESITE = "Lax"
CSRF_COOKIE_SECURE = True
CSRF_COOKIE_HTTPONLY = True
CSRF_COOKIE_SAMESITE = "Lax"

Rails:

# config/initializers/session_store.rb
Rails.application.config.session_store :cookie_store,
  key: "_app_session",
  secure: Rails.env.production?,
  httponly: true,
  same_site: :lax

PHP / WordPress: in wp-config.php oder vor jeder Ausgabe:

ini_set('session.cookie_secure', '1');
ini_set('session.cookie_httponly', '1');
ini_set('session.cookie_samesite', 'Lax');

Welcher SameSite-Wert?

• Strict — Cookie wird nie bei seitenübergreifenden Anfragen gesendet. Maximaler Schutz, bricht aber den Fall, dass Nutzer:innen einem Link auf deine Seite folgen und ausgeloggt ankommen. Gut für hochsensible Flows (Admin, Banking).
• Lax (Default) — Cookie wird bei Top-Level-Navigationen (Klick auf Link) gesendet, aber nicht bei seitenübergreifenden POSTs, iframes oder Bildanfragen. Der richtige Default für die meisten Seiten.
• None — Cookie wird bei allen seitenübergreifenden Anfragen gesendet. Erfordert Secure. Nur wenn du wirklich Drittanbieter-Kontext brauchst (eingebettete Widgets, Identity-Provider).

Cookie-Name-Präfixe fügen eine zweite Durchsetzungsebene hinzu:

• __Secure- — Browser weigert sich, dieses Cookie zu setzen, sofern nicht auch Secure gesetzt ist.
• __Host- — Browser weigert sich ohne Secure, Path=/ und kein Domain-Attribut.

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

Kombiniere diese Regel mit HTTPS, HSTS aktivieren und der Referrer-Policy für eine vollständige Transport-Security-Baseline.

Häufig gestellte Fragen

Wird HttpOnly meinen Client-Code brechen?

Nur, wenn du das Cookie aus JavaScript liest. Für Session-/Auth-Cookies solltest du das nicht — das Cookie sollte für den Client undurchsichtig sein und nur vom Server genutzt werden. Wenn du Daten speicherst, die JS lesen muss, ist das eine andere Kategorie Cookie (Präferenzen, UI-State) und HttpOnly gilt nicht.

Was ist mit Consent- und Analytics-Cookies?

Consent- und Analytics-Cookies müssen oft tatsächlich aus JavaScript lesbar sein. Setze Secure und SameSite=Lax darauf, aber überspringe HttpOnly. Die MetricSpot-Prüfung toleriert das — sie warnt nur, wenn einem Session-Cookie die Flags fehlen.

Wirkt sich das direkt auf GDPR-Compliance aus?

Nicht auf der Einwilligungs-/Rechtsgrundlagen-Seite, aber auf der Sicherheitsseite. GDPR Artikel 32 verlangt „angemessene technische Maßnahmen” — fehlende Cookie-Flags werden in Aufsichtsbehörden-Entscheidungen regelmäßig als Sicherheitsmangel zitiert. Kombiniere mit einem Cookie-Consent-Banner und Datenschutz-Link für die rechtliche Ebene.