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.
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.
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.
# /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; # Variante: SameSite=Strict (blockiert Cookies bei Cross-Site-Navigationen)
proxy_cookie_flags ~ secure httponly samesite=strict; # /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 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.
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.
; /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 Ä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.
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.
Ö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?
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.
Wie steht Ihre Domain bei Sichere Cookies?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.