Sichere Cookies auf Hetzner konfigurieren

Cookie-Security-Flags auf Ihrem Hetzner vServer oder Cloud Server einrichten — Secure, HttpOnly und SameSite auf Webserver- und Applikationsebene. Mit Nginx, Apache und PHP-Konfigurationen.

Hetzner · Schritt für Schritt

Sichere Cookies auf Hetzner

Cookie-Sicherheit wird über drei Flags gesteuert: Secure (nur über HTTPS), HttpOnly (kein JavaScript-Zugriff) und SameSite (CSRF-Schutz). Mit 15 von 166 Punkten ein wichtiger Faktor im Wolf-Agents Web Security Check.

Auf einem Hetzner vServer konfigurieren Sie Cookie-Flags auf zwei Ebenen: Auf Webserver-Ebene (Nginx proxy_cookie_flags oder Apache Header edit) werden Flags nachträglich auf alle Cookies angewendet. Auf Applikationsebene (PHP, Node.js) setzen Sie die Flags direkt beim Erstellen der Cookies. Die Kombination beider Ebenen bietet maximale Sicherheit.

1 Schritt 1 von 3

Cookie-Flags auf Webserver-Ebene setzen

Auf Webserver-Ebene werden die Security-Flags nachträglich auf alle Cookies angewendet — unabhängig davon, ob die Applikation sie bereits setzt. Das ist ein Sicherheitsnetz für den Fall, dass eine Anwendung oder ein Plugin Cookies ohne Flags setzt.

Nginx
/etc/nginx/conf.d/cookie-security.conf Produktiv
# /etc/nginx/conf.d/cookie-security.conf
# proxy_cookie_flags ab Nginx 1.19.3
# Setzt Flags auf ALLE Cookies (~  = Regex-Match auf jeden Cookie-Namen)
proxy_cookie_flags ~ secure httponly samesite=lax;
/etc/nginx/conf.d/cookie-security.conf Variante
# Variante: SameSite=Strict (blockiert Cookies bei Cross-Site-Navigationen)
proxy_cookie_flags ~ secure httponly samesite=strict;
Apache
/etc/apache2/conf-available/cookie-security.conf Produktiv
# /etc/apache2/conf-available/cookie-security.conf
<IfModule mod_headers.c>
    # Secure und HttpOnly an alle Set-Cookie Header anhängen
    Header always edit Set-Cookie "(?i)^((?!;\s*secure).)*$" "$0; Secure"
    Header always edit Set-Cookie "(?i)^((?!;\s*httponly).)*$" "$0; HttpOnly"
    Header always edit Set-Cookie "(?i)^((?!;\s*samesite).)*$" "$0; SameSite=Lax"
</IfModule>
SameSite=Lax vs. SameSite=Strict

SameSite=Lax ist der empfohlene Standard — es erlaubt Cookies bei Top-Level-Navigationen (z.B. Klick auf einen Link), blockiert sie aber bei Cross-Site-POST-Requests. SameSite=Strict blockiert Cookies bei jeder Cross-Site-Navigation, was OAuth-Redirects und Payment-Callbacks brechen kann.

2 Schritt 2 von 3

Applikations-Konfiguration prüfen

Neben der Webserver-Konfiguration sollten Sie die Cookie-Flags auch direkt in der Applikation setzen. Bei PHP-Anwendungen konfigurieren Sie die Session-Cookie-Parameter in der php.ini. Bei Node.js setzen Sie die Flags im Cookie-Middleware oder direkt beim res.cookie() Aufruf.

PHP
/etc/php/8.3/fpm/conf.d/cookie-security.ini Produktiv
; /etc/php/8.3/fpm/conf.d/cookie-security.ini
session.cookie_secure = On
session.cookie_httponly = On
session.cookie_samesite = Lax
session.cookie_lifetime = 0
session.use_strict_mode = On
PHP-FPM nach Änderung neu starten

Änderungen an der php.ini werden erst nach einem Neustart von PHP-FPM wirksam: sudo systemctl restart php8.3-fpm. Prüfen Sie den PHP-Pfad auf Ihrem Hetzner Server — er kann je nach Distribution und PHP-Version abweichen.

3 Schritt 3 von 3

Verifizierung im Browser

Cookie-Flags lassen sich nicht zuverlässig per curl prüfen, da Cookies oft erst nach einer Benutzerinteraktion (Login, Formular) gesetzt werden. Verwenden Sie stattdessen die Browser DevTools.

Browser DevTools: Application > Cookies

Öffnen Sie Chrome/Firefox DevTools (F12), navigieren Sie zu Application > Cookies (Chrome) oder Storage > Cookies (Firefox). Prüfen Sie für jeden Cookie: Ist die Secure-Spalte aktiviert? Ist HttpOnly aktiviert? Welchen SameSite-Wert hat der Cookie?

Testen Sie nach der Konfiguration den Login-Flow, Warenkorb und Payment-Prozess gründlich. Cookie-Flags können bestehende Sessions ungültig machen — weisen Sie Benutzer ggf. auf ein erneutes Login hin.

Häufige Fehler bei Cookies auf Hetzner

Hetzner Load Balancer setzt eigene Cookies

Der Hetzner Load Balancer kann bei aktiviertem Sticky Sessions eigene Cookies setzen (z.B. HCLBSTICKY). Diese Cookies werden vom Load Balancer selbst verwaltet und können nicht über die Backend-Konfiguration beeinflusst werden. Prüfen Sie die Load Balancer-Einstellungen in der Hetzner Cloud Console.

proxy_cookie_flags erfordert Nginx 1.19.3+

Die Direktive proxy_cookie_flags ist erst ab Nginx 1.19.3 verfügbar. Auf älteren Hetzner Images (Debian 10, Ubuntu 18.04) ist eine ältere Nginx-Version vorinstalliert. Prüfen Sie mit nginx -v und aktualisieren Sie bei Bedarf über das offizielle Nginx-Repository.

Webserver vs. Applikation: doppelte Flags

Wenn Webserver und Applikation beide Cookie-Flags setzen, können doppelte Attribute entstehen (z.B. Secure; Secure). Die meisten Browser tolerieren das, aber es ist sauberer, die Apache-Regex so zu gestalten, dass bereits vorhandene Flags nicht dupliziert werden.

SameSite=Strict bricht OAuth-Redirects

SameSite=Strict blockiert Cookies bei Cross-Site-Navigationen — dazu gehören OAuth-Redirects von Google, GitHub oder anderen Providern. Verwenden Sie SameSite=Lax als Standard und setzen Sie Strict nur für besonders sensible Cookies.

Compliance-Relevanz

Sichere Cookie-Konfiguration ist eine zentrale Anforderung des Datenschutzes und der Informationssicherheit. Ungesicherte Cookies können Session-Hijacking und CSRF-Angriffe ermöglichen.

DSGVOArt. 32 — Geeignete technische Maßnahmen zum Schutz personenbezogener Daten (Session-Cookies)
NIS2Art. 21 — Risikomanagementmaßnahmen, Schutz vor unbefugtem Zugriff auf Sessions
BSIAPP.3.1 — Webserver-Absicherung, sichere Session-Verwaltung

Wie steht Ihre Domain bei Sichere Cookies?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.