Cookie-Sicherheitsflags in WordPress beheben

Wenn InspectWP Cookies ohne die Flags Secure, HttpOnly oder SameSite meldet, ist deine Seite möglicherweise anfällig für Session-Hijacking, XSS-basiertes Cookie-Stehlen oder Cross-Site-Request-Forgery-Angriffe (CSRF). Diese drei Flags sind die wichtigsten Cookie-Sicherheitsattribute und arbeiten zusammen, um die Sitzungsdaten deiner Nutzer zu schützen. Glücklicherweise ist die Behebung in WordPress unkompliziert, sobald du verstehst, was jedes Flag bewirkt und wo du es anwendest.

Cookie-Sicherheitsflags und ihre Funktion verstehen

Bevor du Korrekturen anwendest, hilft es zu verstehen, wovor jedes Flag schützt:

• Secure-Flag: Stellt sicher, dass das Cookie nur über HTTPS-Verbindungen gesendet wird. Ohne dieses Flag kann ein Cookie über unverschlüsseltes HTTP übertragen werden, was es einem Angreifer im selben Netzwerk (z. B. öffentliches WLAN) ermöglicht, es mit einem einfachen Paket-Sniffer abzufangen. Sobald der Angreifer das Session-Cookie hat, kann er den Nutzer imitieren. Dieser Angriff ist als Session-Hijacking oder Sidejacking bekannt.
• HttpOnly-Flag: Verhindert, dass JavaScript über document.cookie auf das Cookie zugreift. Dies ist ein kritischer Schutz gegen Cross-Site-Scripting-Angriffe (XSS). Wenn ein Angreifer es schafft, bösartiges JavaScript in deine Seite einzuschleusen (über ein verwundbares Plugin, Kommentarfeld oder Nutzereingabe), verhindert das HttpOnly-Flag, dass dieses Skript Session-Cookies ausliest und an einen externen Server sendet.
• SameSite-Flag: Steuert, ob das Cookie bei Cross-Site-Anfragen gesendet wird. Dies schützt vor CSRF-Angriffen, bei denen eine bösartige Website den Browser des Nutzers dazu bringt, authentifizierte Anfragen an deine Seite zu senden. Das SameSite-Attribut hat drei mögliche Werte:
  • Strict: Das Cookie wird niemals mit Cross-Site-Anfragen gesendet. Dies bietet den stärksten Schutz, kann aber Login-Abläufe unterbrechen, wenn Nutzer Links aus externen Quellen wie E-Mails oder anderen Websites anklicken.
  • Lax: Das Cookie wird bei Top-Level-Navigation (Klick auf einen Link) gesendet, aber nicht bei eingebetteten Anfragen (Bilder, iframes, AJAX). Dies ist der empfohlene Standard für die meisten WordPress-Seiten.
  • None: Das Cookie wird bei allen Anfragen gesendet, einschließlich Cross-Site. Dies muss mit dem Secure-Flag kombiniert werden und wird nur für Cookies benötigt, die in Cross-Site-Kontexten funktionieren müssen, z. B. Payment-Gateway-Integrationen oder eingebettete Widgets.

WordPress-Authentifizierungs-Cookies härten

WordPress setzt mehrere Cookies für eingeloggte Nutzer, darunter wordpress_logged_in_* und wordpress_sec_*. Dies sind die sicherheitskritischsten Cookies auf deiner Seite, da sie den Admin-Zugang steuern. Um sie zu härten, füge die folgenden Konstanten in deine wp-config.php-Datei ein, vor der Zeile "Das ist alles, hör auf zu editieren!":

// Cookies nur über HTTPS senden erzwingen
define('FORCE_SSL_ADMIN', true);

// Cookie-Domain und -Pfad setzen
define('COOKIE_DOMAIN', 'example.com');
define('COOKIEPATH', '/');

// PHP-Session-Cookies härten
@ini_set('session.cookie_secure', '1');
@ini_set('session.cookie_httponly', '1');
@ini_set('session.cookie_samesite', 'Lax');

Die Konstante FORCE_SSL_ADMIN ist besonders wichtig. Sie zwingt WordPress, HTTPS für den Adminbereich und die Login-Seiten zu verwenden, was sicherstellt, dass Authentifizierungs-Cookies nur über verschlüsselte Verbindungen gesetzt werden. Ohne diese Konstante würden Anmeldedaten und Cookies eines Nutzers, der sich über HTTP einloggt, im Klartext übertragen.

Beachte, dass @ini_set nur PHP-Session-Cookies betrifft, nicht die WordPress-spezifischen Cookies. WordPress verwendet eigene Cookie-Setzungsfunktionen, die nicht auf PHP-Sessions basieren. Um WordPress-Cookies speziell zu sichern, benötigst du die unten beschriebenen Server-Level-Ansätze.

Cookie-Flags über die PHP-Konfiguration setzen

Für PHP 7.3 und neuer kannst du Standard-Cookie-Attribute setzen, die für alle Cookies gelten, die durch PHPs setcookie()-Funktion erstellt werden. Füge diese in deine php.ini ein, wenn du Zugriff hast:

session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax

Wenn du keinen Zugriff auf die php.ini hast (was auf Shared Hosting üblich ist), kannst du diese Werte stattdessen in deiner .htaccess-Datei setzen:

# Sichere Cookie-Standards für PHP-Sessions setzen
php_value session.cookie_secure 1
php_value session.cookie_httponly 1
php_value session.cookie_samesite "Lax"

Bedenke, dass diese Einstellungen nur für Cookies gelten, die über PHPs natives Session-Handling erstellt werden. WordPress Core und die meisten Plugins verwenden setcookie() oder wp_set_auth_cookie() direkt, die diese ini-Einstellungen nicht automatisch übernehmen. Für umfassende Abdeckung ist der Server-Level-Header-Ansatz zuverlässiger.

Alle Cookies über Apache .htaccess sichern

Der zuverlässigste Weg, Sicherheitsflags zu allen Cookies auf einem Apache-Server hinzuzufügen, ist die Modifikation des Set-Cookie-Headers auf Server-Ebene. Dies erfasst alle Cookies, einschließlich derjenigen, die von WordPress Core, Plugins und Drittanbieter-Skripten gesetzt werden:

# Sicherheitsflags zu allen Cookies hinzufügen
<IfModule mod_headers.c>
    Header always edit Set-Cookie ^(.*)$ "$1; Secure; HttpOnly; SameSite=Lax"
</IfModule>

Platziere dies in der .htaccess-Datei im Stammverzeichnis deiner Seite. Die Header always edit-Direktive verwendet einen regulären Ausdruck, um alle Set-Cookie-Header abzugleichen und die Sicherheitsflags an jeden anzuhängen.

Es gibt einen wichtigen Vorbehalt bei diesem Ansatz. Wenn ein Cookie bereits eines dieser Flags gesetzt hat (z. B. ein Plugin setzt Secure selbst), könntest du doppelte Flags wie Secure; Secure erhalten. Die meisten Browser behandeln Duplikate problemlos, aber ein sauberer Ansatz verwendet einen Negative Lookahead, um das Hinzufügen bereits vorhandener Flags zu vermeiden:

<IfModule mod_headers.c>
    # Secure-Flag hinzufügen, wenn nicht bereits vorhanden
    Header always edit Set-Cookie "^((?!.*Secure).*)$" "$1; Secure"

    # HttpOnly-Flag hinzufügen, wenn nicht bereits vorhanden
    Header always edit Set-Cookie "^((?!.*HttpOnly).*)$" "$1; HttpOnly"

    # SameSite=Lax hinzufügen, wenn kein SameSite-Attribut vorhanden
    Header always edit Set-Cookie "^((?!.*SameSite).*)$" "$1; SameSite=Lax"
</IfModule>

Diese Version prüft jedes Cookie einzeln und fügt das Flag nur hinzu, wenn es nicht bereits vorhanden ist. Sie ist ausführlicher, vermeidet aber potenzielle Probleme mit doppelten Attributen.

Alle Cookies über die Nginx-Konfiguration sichern

Für Nginx-Server hängt der Ansatz von deiner Nginx-Version ab:

Nginx 1.19.3 und neuer unterstützt die proxy_cookie_flags-Direktive nativ:

# In deinem Server- oder Location-Block
proxy_cookie_flags ~ secure httponly samesite=lax;

Die ~ matcht alle Cookies. Du kannst auch bestimmte Cookies nach Name ansprechen:

# Nur auf WordPress-Session-Cookies anwenden
proxy_cookie_flags wordpress_logged_in_* secure httponly samesite=lax;
proxy_cookie_flags wordpress_sec_* secure httponly samesite=lax;

Ältere Nginx-Versionen (vor 1.19.3) können die proxy_cookie_path-Direktive als Workaround verwenden:

# Workaround für ältere Nginx-Versionen
proxy_cookie_path / "/; Secure; HttpOnly; SameSite=Lax";

Wenn du Nginx als Reverse Proxy vor Apache oder PHP-FPM verwendest, musst du möglicherweise auch Header mit dem more_set_headers-Modul oder der add_header-Direktive hinzufügen. Allerdings modifiziert add_header keine Set-Cookie-Header, daher ist proxy_cookie_flags der korrekte Ansatz.

Cookies auf Cloudflare- oder CDN-proxied Seiten sichern

Wenn deine WordPress-Seite hinter Cloudflare oder einem anderen CDN-Proxy steht, beinhaltet das Cookie-Handling eine zusätzliche Schicht. Cloudflare setzt eigene Cookies (wie __cf_bm für Bot-Management), und diese werden von Cloudflare kontrolliert, nicht von deiner Server-Konfiguration. Du kannst Cloudflare-Cookies nicht über .htaccess oder Nginx-Config mit Sicherheitsflags versehen.

Cloudflare-Cookies enthalten standardmäßig bereits die Flags Secure und HttpOnly. Wenn InspectWP ein Cloudflare-Cookie als fehlend markiert, handelt es sich wahrscheinlich um ein Anzeigeproblem oder ein Cookie eines Cloudflare-Features, das bestimmte Flags absichtlich weglässt (z. B. Analytics-Cookies, die JavaScript-Zugriff benötigen und daher kein HttpOnly haben).

Für Cookies, die von deinem Origin-Server gesetzt werden, funktionieren die oben beschriebenen .htaccess- oder Nginx-Fixes auch dann korrekt, wenn Cloudflare davor sitzt. Cloudflare leitet Set-Cookie-Header von deinem Server unverändert an den Client weiter.

Plugin-Cookies ohne Sicherheitsflags behandeln

Viele WordPress-Plugins setzen eigene Cookies, und nicht alle enthalten korrekte Sicherheitsflags. Häufige Kandidaten sind:

• Cookie-Consent-Plugins: Plugins wie CookieYes, Complianz oder GDPR Cookie Consent setzen Cookies, um die Einwilligungsentscheidung des Nutzers zu speichern. Prüfe die Einstellungen jedes Plugins auf eine Option "Sichere Cookies" oder "Cookie-Sicherheit". Einige Plugins haben diese Optionen in neueren Versionen hinzugefügt.
• Analytics- und Tracking-Plugins: Google Analytics, Matomo und ähnliche Plugins setzen möglicherweise Tracking-Cookies ohne Sicherheitsflags. Der Server-Level-Header-Ansatz (Apache/Nginx) ist die beste Lösung, da die Plugins selten eine Cookie-Flag-Konfiguration bieten.
• Caching-Plugins: WP Rocket, LiteSpeed Cache und andere setzen Cache-Identifier-Cookies, denen möglicherweise Flags fehlen. Auch hier greift der Server-Level-Ansatz automatisch.
• WooCommerce: WooCommerce setzt mehrere Cookies für Warenkorbdaten und Session-Management. Neuere Versionen von WooCommerce (5.0+) setzen das Secure-Flag, wenn die Seite HTTPS verwendet, ältere Versionen jedoch möglicherweise nicht. Aktualisiere WooCommerce auf die neueste Version und wende den Server-Level-Header-Fix als Sicherheitsnetz an.
• Login- und Mitgliedschafts-Plugins: Plugins wie MemberPress, Restrict Content Pro oder WP-Members setzen möglicherweise eigene Session-Cookies. Prüfe auf Plugin-Updates, da viele als Reaktion auf Browser-Änderungen rund um die SameSite-Durchsetzung Sicherheitsflag-Unterstützung hinzugefügt haben.

Der Server-Level-Ansatz (Apache Header edit oder Nginx proxy_cookie_flags) ist die zuverlässigste Lösung, weil er alle Cookies erfasst, unabhängig davon, welches Plugin oder Skript sie setzt. Selbst wenn ein Plugin-Update die Flags entfernt, fügt deine Server-Konfiguration sie wieder hinzu.

Besondere Überlegungen für SameSite=None-Cookies

Manche Funktionalitäten erfordern, dass Cookies in Cross-Site-Kontexten gesendet werden. Häufige Beispiele:

• Payment-Gateway-Callbacks: Dienste wie PayPal, Stripe oder Mollie leiten Nutzer nach der Zahlung zurück auf deine Seite. Wenn dein Session-Cookie SameSite=Strict verwendet, wird der Nutzer nach der Weiterleitung abgemeldet, weil der Browser das Cookie nicht mit der Cross-Site-Navigation sendet.
• Eingebettete Inhalte (iframes): Wenn deine WordPress-Seite in einem iframe auf einer anderen Domain eingebettet ist, benötigen Cookies SameSite=None; Secure, um zu funktionieren. Dies ist relevant für Headless-WordPress-Setups oder Seiten, die einbettbare Widgets bereitstellen.
• OAuth- und SSO-Flows: Single-Sign-On-Implementierungen, die durch Drittanbieter-Identity-Provider weiterleiten, benötigen möglicherweise SameSite=None für das Session-Cookie während des Authentifizierungsflusses.

Wenn du SameSite=None für bestimmte Cookies brauchst, während du SameSite=Lax als Standard behältst, benötigst du eine gezieltere Konfiguration. In Apache:

<IfModule mod_headers.c>
    # Standard: SameSite=Lax zu allen Cookies hinzufügen
    Header always edit Set-Cookie "^((?!.*SameSite).*)$" "$1; SameSite=Lax"

    # Überschreibung für bestimmte Cookies, die Cross-Site-Zugriff benötigen
    Header always edit Set-Cookie "(payment_session=.*)" "$1; SameSite=None; Secure"
</IfModule>

Cookie-Sicherheit über ein WordPress-Plugin hinzufügen

Wenn du keinen Zugriff auf Server-Konfigurationsdateien hast (üblich bei Managed WordPress Hosting), kannst du ein WordPress-Plugin verwenden, um Cookie-Sicherheitsflags hinzuzufügen. Der Plugin-Ansatz funktioniert, indem er sich in den wp_headers-Filter einklinkt oder PHPs header()-Funktion verwendet, um Set-Cookie-Header zu modifizieren, bevor sie an den Browser gesendet werden:

function add_cookie_security_flags($headers) {
    // Dies betrifft Header, die von WordPress gesendet werden
    if (is_ssl()) {
        $headers['Set-Cookie'] = 'Secure; HttpOnly; SameSite=Lax';
    }
    return $headers;
}
add_filter('wp_headers', 'add_cookie_security_flags');

// Für Cookie-Sicherheit auf PHP-Ebene
function enforce_cookie_security() {
    if (is_ssl() && PHP_VERSION_ID >= 70300) {
        ini_set('session.cookie_secure', '1');
        ini_set('session.cookie_httponly', '1');
        ini_set('session.cookie_samesite', 'Lax');
    }
}
add_action('init', 'enforce_cookie_security', 1);

Dieser Ansatz hat Einschränkungen. Er betrifft nur Cookies, die nach dem WordPress-init-Hook gesetzt werden, und kann keine Cookies modifizieren, die von JavaScript oder externen Skripten gesetzt werden. Der Server-Level-Ansatz ist immer umfassender.

Cookie-Sicherheitsflags nach dem Anwenden der Fixes überprüfen

Nach der Implementierung deiner Fixes ist gründliches Testen unerlässlich, um zu bestätigen, dass alles korrekt funktioniert:

1. Alle Browser-Cookies löschen: Öffne die Entwicklertools deines Browsers, gehe zum Application-Tab (Chrome) oder Storage-Tab (Firefox) und lösche alle Cookies für deine Domain. Das stellt sicher, dass du frische Cookies mit den neuen Flags testest.
2. Seite besuchen und einloggen: Nach dem Einloggen gehe zurück zu den Entwicklertools und inspiziere jedes Cookie. In Chrome zeigt das Application > Cookies-Panel Spalten für Secure, HttpOnly und SameSite. Jedes Authentifizierungs-Cookie sollte ein Häkchen für Secure und HttpOnly zeigen und "Lax" für SameSite anzeigen.
3. Kritische Nutzerflows testen: Navigiere durch die wichtigsten Funktionen deiner Seite: füge Artikel zum Warenkorb hinzu (bei WooCommerce), sende Formulare ab, durchlaufe den Checkout-Prozess und nutze Mitgliedschaftsfunktionen. SameSite-Änderungen können gelegentlich Cross-Site-Flows unterbrechen, also teste alles, was Weiterleitungen von externen Diensten beinhaltet.
4. Login über externe Links testen: Sende dir selbst eine Passwort-Reset-E-Mail und klicke auf den Link. Wenn du SameSite=Strict verwendest (nicht empfohlen), kann dieser Flow brechen, weil das Cookie nicht mit der Cross-Site-Navigation vom E-Mail-Client gesendet wird.
5. InspectWP erneut ausführen: Führe einen frischen Scan deiner Seite mit InspectWP durch, um zu bestätigen, dass alle Cookie-Sicherheitswarnungen behoben sind. InspectWP prüft jedes Cookie einzeln, sodass du genau sehen kannst, welche Cookies jetzt die korrekten Flags haben.

Häufige Probleme nach dem Aktivieren der Cookie-Sicherheitsflags beheben

• Nutzer werden nach dem Klicken auf E-Mail-Links ausgeloggt: Dies passiert, wenn SameSite=Strict gesetzt ist. Wechsle zu SameSite=Lax, das Cookies bei Top-Level-Navigationen von externen Seiten erlaubt, während eingebettete Cross-Site-Anfragen weiterhin blockiert werden.
• Payment-Gateway-Integration funktioniert nicht mehr: Einige Zahlungsanbieter leiten Nutzer während des Checkouts über ihre eigene Domain weiter. Wenn das Session-Cookie nach der Weiterleitung nicht gesendet wird, verliert der Nutzer seinen Warenkorb oder Login-Status. Setze das Payment-Session-Cookie spezifisch auf SameSite=None; Secure, während du andere Cookies auf SameSite=Lax belässt.
• Cookie-Consent-Banner erscheint immer wieder: Wenn das Cookie des Cookie-Consent-Plugins ohne das Secure-Flag gesetzt wird und deine Seite von HTTP auf HTTPS weiterleitet, wird das auf HTTP gesetzte Cookie nicht über HTTPS gesendet, was dazu führt, dass das Banner erneut erscheint. Stelle sicher, dass deine Seite vollständig auf HTTPS läuft und das Consent-Cookie das Secure-Flag enthält.
• Caching-Konflikte: Einige Caching-Plugins cachen die Set-Cookie-Header zusammen mit dem Seiteninhalt. Nachdem du Server-Level-Cookie-Flag-Änderungen angewendet hast, leere deinen gesamten Cache (sowohl Seiten-Cache als auch Object-Cache), um sicherzustellen, dass die neuen Header wirksam werden.
• Doppelte Cookie-Flags: Wenn du Attribute wie Secure; Secure oder SameSite=Lax; SameSite=Lax in deinen Cookies siehst, hast du mehrere Schichten, die dieselben Flags hinzufügen. Prüfe deine .htaccess, wp-config.php, PHP-ini-Einstellungen und alle Sicherheitsplugins auf überlappende Konfigurationen. Verwende den Negative-Lookahead-Regex-Ansatz in der .htaccess, um Duplikate zu vermeiden.

Cookie-Sicherheits-Best-Practices für WordPress

• Immer HTTPS verwenden: Das Secure-Flag ist ohne HTTPS bedeutungslos. Stelle sicher, dass deine gesamte Seite über HTTPS geladen wird, einschließlich aller Ressourcen (Bilder, Skripte, Stylesheets). Verwende die FORCE_SSL_ADMIN-Konstante und erwäge einen HSTS-Header, um jeglichen HTTP-Zugriff zu verhindern.
• Standard auf SameSite=Lax setzen: Dies bietet starken CSRF-Schutz, ohne die normale Navigation zu beeinträchtigen. Verwende SameSite=None nur für bestimmte Cookies, die genuinen Cross-Site-Zugriff benötigen, und verwende SameSite=Strict nur, wenn du sicher bist, dass keine externe Navigation zu deiner Seite Sessions aufrechterhalten muss.
• Flags auf Server-Ebene anwenden: Server-Level-Konfiguration (Apache .htaccess oder Nginx-Config) erfasst alle Cookies unabhängig vom Ursprung. Dies ist zuverlässiger als Plugin-Level- oder PHP-Level-Ansätze.
• WordPress und Plugins aktuell halten: Moderne Versionen von WordPress Core und den meisten beliebten Plugins setzen korrekte Cookie-Flags, wenn HTTPS aktiv ist. Alles aktuell zu halten reduziert die Anzahl unsicherer Cookies, die du auf Server-Ebene beheben musst.
• Cookies regelmäßig prüfen: Führe periodische InspectWP-Scans durch, um neue Cookies zu erkennen, die durch Plugin-Updates oder neue Integrationen eingeführt werden. Cookie-Sicherheit ist keine einmalige Maßnahme, sondern erfordert fortlaufende Aufmerksamkeit, während sich deine Seite weiterentwickelt.
• Auf mehreren Browsern testen: Chrome, Firefox, Safari und Edge behandeln Cookie-Attribute jeweils etwas unterschiedlich. Chrome ist der strengste Durchsetzer von SameSite-Richtlinien, während Safari seine eigene Intelligent Tracking Prevention hat, die das Cookie-Verhalten beeinflusst. Teste deine Seite nach Änderungen auf allen großen Browsern.