Cookie-Sicherheit mit Cloudflare konfigurieren
Schritt-für-Schritt-Anleitung: Secure, HttpOnly und SameSite über Cloudflare Workers einrichten — mit Transform Rules als Dashboard-Alternative und fertigen Worker-Scripts zum Kopieren.
Sichere Cookies mit Cloudflare
Cloudflare sitzt als Reverse Proxy vor Ihrer Origin und kann Cookie-Header am Edge modifizieren — bevor sie den Browser erreichen. Cloudflare Workers ermöglichen volle programmatische Kontrolle: bestehende Set-Cookie-Header werden gelesen, fehlende Flags ergänzt und der modifizierte Header zurückgeschrieben.
Als einfachere Alternative bieten Transform Rules im Dashboard eine No-Code-Lösung — mit einer wichtigen Einschränkung: Transform Rules können nur neue Header-Werte anfügen, keine bestehenden modifizieren. Diese Anleitung zeigt beide Wege und hilft Ihnen, den richtigen für Ihren Anwendungsfall zu wählen. Der Wolf-Agents Web Security Check prüft Cookie-Flags automatisch — als Teil der 166 Prüfpunkte.
Cloudflare Workers für Cookie-Flag-Injection
Ein Cloudflare Worker ist die empfohlene Methode für Cookie-Absicherung: Er fängt die Response vom Origin ab, liest den Set-Cookie-Header und fügt fehlende Flags hinzu. Der Worker läuft am Cloudflare-Edge — ohne Latenz-Overhead und mit 100.000 kostenlosen Requests pro Tag im Free-Plan.
// Cloudflare Workers — Cookie-Flags via Response-Modifikation
export default {
async fetch(request) {
const response = await fetch(request);
const newResponse = new Response(response.body, response);
// Set-Cookie-Header modifizieren
const setCookie = newResponse.headers.get('Set-Cookie');
if (setCookie) {
// Flags hinzufügen (wenn nicht bereits vorhanden)
let modifiedCookie = setCookie;
if (!modifiedCookie.includes('Secure')) modifiedCookie += '; Secure';
if (!modifiedCookie.includes('HttpOnly')) modifiedCookie += '; HttpOnly';
if (!modifiedCookie.includes('SameSite')) modifiedCookie += '; SameSite=Strict';
newResponse.headers.set('Set-Cookie', modifiedCookie);
}
return newResponse;
}
};Wenn Ihre Anwendung mehrere Set-Cookie-Header sendet, verwenden Sie getAll() statt get(). Das folgende Script verarbeitet alle Cookie-Header korrekt:
// Mehrere Set-Cookie-Header korrekt verarbeiten
export default {
async fetch(request) {
const response = await fetch(request);
const newResponse = new Response(response.body, response);
// getAll() für mehrere Cookies verwenden
const cookies = newResponse.headers.getAll('Set-Cookie');
// Alle vorhandenen Set-Cookie-Header entfernen
newResponse.headers.delete('Set-Cookie');
// Jeden Cookie einzeln absichern und neu setzen
for (const cookie of cookies) {
let modified = cookie;
if (!modified.includes('Secure')) modified += '; Secure';
if (!modified.includes('HttpOnly')) modified += '; HttpOnly';
if (!modified.includes('SameSite')) modified += '; SameSite=Strict';
newResponse.headers.append('Set-Cookie', modified);
}
return newResponse;
}
};wrangler deployTransform Rules als Alternative (Dashboard)
Transform Rules ermöglichen Header-Modifikation ohne Code — direkt im Cloudflare Dashboard. Sie eignen sich als schneller Einstieg, haben aber eine wichtige Einschränkung: Sie können keine bestehenden Set-Cookie-Header modifizieren, sondern nur neue hinzufügen. Für Anwendungen mit eigenen Cookies sind Workers die bessere Wahl.
# Cloudflare Dashboard — Transform Rules
# Rules → Transform Rules → HTTP Response Header Modification
# Schritt 1: Rule erstellen
Name: Cookie Security Flags
When: Hostname equals ihre-domain.de
Then: Set static header
# Schritt 2: Header-Modifikation konfigurieren
Field: Set-Cookie
Action: Add
Value: Secure; HttpOnly; SameSite=Strict
# WICHTIG: Transform Rules können nur Header hinzufügen,
# nicht bestehende Set-Cookie-Header modifizieren.
# Für echte Header-Modifikation → Workers verwenden.| Methode | Header modifizieren | Verfügbarkeit |
|---|---|---|
| Cloudflare Workers | Ja — lesen, modifizieren, schreiben | Free-Plan (100k Req/Tag) |
| Transform Rules | Nur hinzufügen (nicht modifizieren) | Pro-Plan ($20/Monat) |
| Origin-Anwendung | Ja — vollständige Kontrolle | Immer (empfohlen) |
Cookie-Prefixes und SameSite-Konfiguration
Cookie-Prefixes (__Host-, __Secure-) müssen im Backend gesetzt werden — sie sind Teil des Cookie-Namens und können nicht nachträglich hinzugefügt werden. Der Cloudflare Worker ergänzt fehlende Attribute als Sicherheitsnetz und kann SameSite je nach Cookie-Typ (Session vs. Analytics) gezielt steuern.
// Worker: Cookie-Prefixes korrekt behandeln
// __Host- und __Secure- Prefixes werden vom Backend gesetzt
export default {
async fetch(request) {
const response = await fetch(request);
const newResponse = new Response(response.body, response);
const cookies = newResponse.headers.getAll('Set-Cookie');
newResponse.headers.delete('Set-Cookie');
for (const cookie of cookies) {
let modified = cookie;
// __Host- Cookies brauchen Secure + Path=/ (kein Domain)
// Worker ergänzt nur fehlende Flags als Sicherheitsnetz
if (!modified.includes('Secure')) modified += '; Secure';
if (!modified.includes('HttpOnly')) modified += '; HttpOnly';
// SameSite nur setzen wenn nicht vorhanden
if (!modified.includes('SameSite')) {
// Lax für Cookies die Cross-Site-Navigation brauchen
const isSessionCookie = modified.startsWith('__Host-session')
|| modified.startsWith('__Secure-session');
modified += isSessionCookie
? '; SameSite=Strict'
: '; SameSite=Lax';
}
newResponse.headers.append('Set-Cookie', modified);
}
return newResponse;
}
};SameSite=None ohne Secure — Browser lehnen solche Cookies ab. Verifizierung mit Cloudflare
Nach dem Deploy prüfen Sie mit curl, ob die Cookie-Flags korrekt vom Cloudflare-Edge geliefert werden. Mit wrangler tail können Sie Worker-Logs in Echtzeit beobachten — hilfreich bei der Fehlersuche. Der Response-Header cf-ray bestätigt, dass die Antwort über Cloudflare läuft.
# 1. Worker deployen
wrangler deploy
# 2. Cookie-Flags per curl verifizieren
curl -sI https://ihre-domain.de/login | grep -i set-cookie
# Erwartete Ausgabe:
# Set-Cookie: session=...; Secure; HttpOnly; SameSite=Strict
# 3. Worker-Logs in Echtzeit prüfen
wrangler tail
# 4. Cloudflare Dashboard: Security → Overview
# → Prüfen ob der Worker auf allen Requests feuertÖffnen Sie DevTools (F12) → Application → Cookies → Ihre Domain. Prüfen Sie die Spalten HttpOnly, Secure und SameSite für jeden Cookie. Der cf-cache-status-Header in der Network-Ansicht zeigt, ob Cloudflare die Response gecacht hat.
Auch verfügbar für:
Wie steht Ihre Domain bei Cookie-Sicherheit?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Workers oder Transform Rules — was soll ich für Cookie-Flags verwenden?
Cloudflare Workers sind die flexiblere Lösung: Sie können bestehende Set-Cookie-Header lesen, modifizieren und gezielt Flags hinzufügen — ohne Duplikate. Transform Rules (Dashboard) können nur neue Header-Werte anfügen, nicht bestehende modifizieren. Für produktive Anwendungen sind Workers empfohlen, Transform Rules eignen sich nur als schneller Einstieg ohne bestehende Cookies.
Funktioniert Cookie-Absicherung über Cloudflare auch im Free-Plan?
Cloudflare Workers sind im Free-Plan mit 100.000 Requests/Tag verfügbar — ausreichend fuer die meisten kleineren Websites. Transform Rules sind im Free-Plan mit bis zu 10 Regeln nutzbar. Fuer Cookie-Sicherheit ohne Upgrade empfiehlt sich, die Flags direkt in der Origin-Anwendung zu setzen.
Wie setze ich Cookie-Flags mit Cloudflare Workers?
Sie erstellen einen Worker, der den Request an den Origin weiterleitet, die Set-Cookie-Header der Response ausliest und fehlende Flags (Secure, HttpOnly, SameSite) per String-Konkatenation ergänzt. Der modifizierte Header wird mit newResponse.headers.set() zurückgeschrieben. Achten Sie darauf, bereits vorhandene Flags nicht doppelt zu setzen — prüfen Sie mit includes() vor dem Anhängen.
Kann Cloudflare mehrere Set-Cookie-Header verarbeiten?
Ja, aber Vorsicht: Die Headers API gibt bei get("Set-Cookie") nur den ersten Header zurück. Für mehrere Cookies müssen Sie getAll("Set-Cookie") verwenden (verfügbar in Workers) und jeden Cookie-Header einzeln modifizieren. Wird dies nicht beachtet, werden nur die Flags des ersten Cookies gesetzt.
Verlangsamt ein Cloudflare Worker die Response?
Kaum messbar. Cloudflare Workers laufen direkt am Edge (200+ PoPs weltweit) und haben eine Latenz von unter 1 ms für einfache Header-Operationen. Der Overhead für String-Manipulation bei Set-Cookie ist vernachlässigbar — deutlich geringer als eine zusätzliche Netzwerk-Roundtrip zum Origin.
Was passiert mit Cookies, die der Origin bereits mit korrekten Flags setzt?
Der Worker prüft per includes() ob ein Flag bereits vorhanden ist. Wenn Secure, HttpOnly oder SameSite schon gesetzt sind, werden sie nicht erneut angehängt. Diese doppelte Absicherung ist eine Best Practice: Der Origin setzt Flags korrekt, Cloudflare dient als Sicherheitsnetz für den Fall, dass ein Flag versehentlich fehlt.
Funktionieren Cookie-Prefixes (__Host-) zusammen mit Cloudflare?
__Host- und __Secure- Prefixes müssen im Backend (Origin-Anwendung) im Cookie-Namen gesetzt werden. Cloudflare leitet diese unverändert weiter. Der Worker kann die Flags zusätzlich absichern, aber den Prefix selbst nicht im nachhinein hinzufügen — der Prefix ist Teil des Cookie-Namens, nicht der Attribute.