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.

Cloudflare · Schritt für Schritt

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.

1 Schritt 1 von 4

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.

worker.js Cloudflare Worker
// 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;
  }
};
Mehrere Cookies gleichzeitig?

Wenn Ihre Anwendung mehrere Set-Cookie-Header sendet, verwenden Sie getAll() statt get(). Das folgende Script verarbeitet alle Cookie-Header korrekt:

worker.js — Multi-Cookie-Variante Erweitert
// 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;
  }
};
Worker deployen und aktivieren:
wrangler deploy
2 Schritt 2 von 4

Transform 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 Dashboard
# 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)
Die sicherste Lösung: Setzen Sie Cookie-Flags direkt in Ihrer Anwendung (PHP, Node.js, Python) und verwenden Sie Cloudflare Workers als Sicherheitsnetz für Cookies, die versehentlich ohne Flags gesetzt werden.
3 Schritt 3 von 4

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.js — Prefixes & SameSite Prefixes
// 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;
  }
};
Transform Rules können keine bestehenden Set-Cookie-Header modifizieren, nur neue hinzufügen. Für echte Header-Modifikation verwenden Sie Workers oder konfigurieren Cookies direkt in der Origin-Anwendung. Setzen Sie niemals SameSite=None ohne Secure — Browser lehnen solche Cookies ab.
4 Schritt 4 von 4

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.

Terminal Verifizierung
# 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
Browser DevTools als Alternative

Ö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.

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.