Cookie-Sicherheitsflags in WordPress beheben

Wenn InspectWP Cookies ohne die Flags Secure, HttpOnly oder SameSite meldet, ist deine Seite moeglicherweise anfaellig fuer 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 schuetzen. Gluecklicherweise 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 schuetzt:

• Secure-Flag: Stellt sicher, dass das Cookie nur ueber HTTPS-Verbindungen gesendet wird. Ohne dieses Flag kann ein Cookie ueber unverschluesseltes HTTP uebertragen werden, was es einem Angreifer im selben Netzwerk (z. B. oeffentliches WLAN) ermoeglicht, 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 ueber document.cookie auf das Cookie zugreift. Dies ist ein kritischer Schutz gegen Cross-Site-Scripting-Angriffe (XSS). Wenn ein Angreifer es schafft, boesartiges JavaScript in deine Seite einzuschleusen (ueber 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 schuetzt vor CSRF-Angriffen, bei denen eine boesartige Website den Browser des Nutzers dazu bringt, authentifizierte Anfragen an deine Seite zu senden. Das SameSite-Attribut hat drei moegliche Werte:
  • Strict: Das Cookie wird niemals mit Cross-Site-Anfragen gesendet. Dies bietet den staerksten Schutz, kann aber Login-Ablaeufe 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 fuer die meisten WordPress-Seiten.
  • None: Das Cookie wird bei allen Anfragen gesendet, einschliesslich Cross-Site. Dies muss mit dem Secure-Flag kombiniert werden und wird nur fuer Cookies benoetigt, die in Cross-Site-Kontexten funktionieren muessen, z. B. Payment-Gateway-Integrationen oder eingebettete Widgets.

WordPress-Authentifizierungs-Cookies haerten

WordPress setzt mehrere Cookies fuer 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 haerten, fuege die folgenden Konstanten in deine wp-config.php-Datei ein, vor der Zeile "Das ist alles, hoer auf zu editieren!":

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

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

// PHP-Session-Cookies haerten
@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 fuer den Adminbereich und die Login-Seiten zu verwenden, was sicherstellt, dass Authentifizierungs-Cookies nur ueber verschluesselte Verbindungen gesetzt werden. Ohne diese Konstante wuerden Anmeldedaten und Cookies eines Nutzers, der sich ueber HTTP einloggt, im Klartext uebertragen.

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, benoetigst du die unten beschriebenen Server-Level-Ansaetze.

Cookie-Flags ueber die PHP-Konfiguration setzen

Fuer PHP 7.3 und neuer kannst du Standard-Cookie-Attribute setzen, die fuer alle Cookies gelten, die durch PHPs setcookie()-Funktion erstellt werden. Fuege 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 ueblich ist), kannst du diese Werte stattdessen in deiner .htaccess-Datei setzen:

# Sichere Cookie-Standards fuer 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 fuer Cookies gelten, die ueber 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 uebernehmen. Fuer umfassende Abdeckung ist der Server-Level-Header-Ansatz zuverlaessiger.

Alle Cookies ueber Apache .htaccess sichern

Der zuverlaessigste Weg, Sicherheitsflags zu allen Cookies auf einem Apache-Server hinzuzufuegen, ist die Modifikation des Set-Cookie-Headers auf Server-Ebene. Dies erfasst alle Cookies, einschliesslich derjenigen, die von WordPress Core, Plugins und Drittanbieter-Skripten gesetzt werden:

# Sicherheitsflags zu allen Cookies hinzufuegen
<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 regulaeren Ausdruck, um alle Set-Cookie-Header abzugleichen und die Sicherheitsflags an jeden anzuhaengen.

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

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

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

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

Diese Version prueft jedes Cookie einzeln und fuegt das Flag nur hinzu, wenn es nicht bereits vorhanden ist. Sie ist ausfuehrlicher, vermeidet aber potenzielle Probleme mit doppelten Attributen.

Alle Cookies ueber die Nginx-Konfiguration sichern

Fuer Nginx-Server haengt der Ansatz von deiner Nginx-Version ab:

Nginx 1.19.3 und neuer unterstuetzt 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;

Aeltere Nginx-Versionen (vor 1.19.3) koennen die proxy_cookie_path-Direktive als Workaround verwenden:

# Workaround fuer aeltere Nginx-Versionen
proxy_cookie_path / "/; Secure; HttpOnly; SameSite=Lax";

Wenn du Nginx als Reverse Proxy vor Apache oder PHP-FPM verwendest, musst du moeglicherweise auch Header mit dem more_set_headers-Modul oder der add_header-Direktive hinzufuegen. 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 zusaetzliche Schicht. Cloudflare setzt eigene Cookies (wie __cf_bm fuer Bot-Management), und diese werden von Cloudflare kontrolliert, nicht von deiner Server-Konfiguration. Du kannst Cloudflare-Cookies nicht ueber .htaccess oder Nginx-Config mit Sicherheitsflags versehen.

Cloudflare-Cookies enthalten standardmaessig 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 weglasst (z. B. Analytics-Cookies, die JavaScript-Zugriff benoetigen und daher kein HttpOnly haben).

Fuer 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 unveraendert an den Client weiter.

Plugin-Cookies ohne Sicherheitsflags behandeln

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

• Cookie-Consent-Plugins: Plugins wie CookieYes, Complianz oder GDPR Cookie Consent setzen Cookies, um die Einwilligungsentscheidung des Nutzers zu speichern. Pruefe die Einstellungen jedes Plugins auf eine Option "Sichere Cookies" oder "Cookie-Sicherheit". Einige Plugins haben diese Optionen in neueren Versionen hinzugefuegt.
• Analytics- und Tracking-Plugins: Google Analytics, Matomo und aehnliche Plugins setzen moeglicherweise Tracking-Cookies ohne Sicherheitsflags. Der Server-Level-Header-Ansatz (Apache/Nginx) ist die beste Loesung, da die Plugins selten eine Cookie-Flag-Konfiguration bieten.
• Caching-Plugins: WP Rocket, LiteSpeed Cache und andere setzen Cache-Identifier-Cookies, denen moeglicherweise Flags fehlen. Auch hier greift der Server-Level-Ansatz automatisch.
• WooCommerce: WooCommerce setzt mehrere Cookies fuer Warenkorbdaten und Session-Management. Neuere Versionen von WooCommerce (5.0+) setzen das Secure-Flag, wenn die Seite HTTPS verwendet, aeltere Versionen jedoch moeglicherweise 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 moeglicherweise eigene Session-Cookies. Pruefe auf Plugin-Updates, da viele als Reaktion auf Browser-Aenderungen rund um die SameSite-Durchsetzung Sicherheitsflag-Unterstuetzung hinzugefuegt haben.

Der Server-Level-Ansatz (Apache Header edit oder Nginx proxy_cookie_flags) ist die zuverlaessigste Loesung, weil er alle Cookies erfasst, unabhaengig davon, welches Plugin oder Skript sie setzt. Selbst wenn ein Plugin-Update die Flags entfernt, fuegt deine Server-Konfiguration sie wieder hinzu.

Besondere Ueberlegungen fuer SameSite=None-Cookies

Manche Funktionalitaeten erfordern, dass Cookies in Cross-Site-Kontexten gesendet werden. Haeufige Beispiele:

• Payment-Gateway-Callbacks: Dienste wie PayPal, Stripe oder Mollie leiten Nutzer nach der Zahlung zurueck 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, benoetigen Cookies SameSite=None; Secure, um zu funktionieren. Dies ist relevant fuer Headless-WordPress-Setups oder Seiten, die einbettbare Widgets bereitstellen.
• OAuth- und SSO-Flows: Single-Sign-On-Implementierungen, die durch Drittanbieter-Identity-Provider weiterleiten, benoetigen moeglicherweise SameSite=None fuer das Session-Cookie waehrend des Authentifizierungsflusses.

Wenn du SameSite=None fuer bestimmte Cookies brauchst, waehrend du SameSite=Lax als Standard behaeltst, benoetigst du eine gezieltere Konfiguration. In Apache:

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

    # Ueberschreibung fuer bestimmte Cookies, die Cross-Site-Zugriff benoetigen
    Header always edit Set-Cookie "(payment_session=.*)" "$1; SameSite=None; Secure"
</IfModule>

Cookie-Sicherheit ueber ein WordPress-Plugin hinzufuegen

Wenn du keinen Zugriff auf Server-Konfigurationsdateien hast (ueblich bei Managed WordPress Hosting), kannst du ein WordPress-Plugin verwenden, um Cookie-Sicherheitsflags hinzuzufuegen. 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');

// Fuer 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 Einschraenkungen. 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 ueberpruefen

Nach der Implementierung deiner Fixes ist gruendliches Testen unerlaeßlich, um zu bestaetigen, dass alles korrekt funktioniert:

1. Alle Browser-Cookies loeschen: Oeffne die Entwicklertools deines Browsers, gehe zum Application-Tab (Chrome) oder Storage-Tab (Firefox) und loesche alle Cookies fuer deine Domain. Das stellt sicher, dass du frische Cookies mit den neuen Flags testest.
2. Seite besuchen und einloggen: Nach dem Einloggen gehe zurueck zu den Entwicklertools und inspiziere jedes Cookie. In Chrome zeigt das Application > Cookies-Panel Spalten fuer Secure, HttpOnly und SameSite. Jedes Authentifizierungs-Cookie sollte ein Haekchen fuer Secure und HttpOnly zeigen und "Lax" fuer SameSite anzeigen.
3. Kritische Nutzerflows testen: Navigiere durch die wichtigsten Funktionen deiner Seite: fuege Artikel zum Warenkorb hinzu (bei WooCommerce), sende Formulare ab, durchlaufe den Checkout-Prozess und nutze Mitgliedschaftsfunktionen. SameSite-Aenderungen koennen gelegentlich Cross-Site-Flows unterbrechen, also teste alles, was Weiterleitungen von externen Diensten beinhaltet.
4. Login ueber 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 ausfuehren: Fuehre einen frischen Scan deiner Seite mit InspectWP durch, um zu bestaetigen, dass alle Cookie-Sicherheitswarnungen behoben sind. InspectWP prueft jedes Cookie einzeln, sodass du genau sehen kannst, welche Cookies jetzt die korrekten Flags haben.

Haeufige 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, waehrend eingebettete Cross-Site-Anfragen weiterhin blockiert werden.
• Payment-Gateway-Integration funktioniert nicht mehr: Einige Zahlungsanbieter leiten Nutzer waehrend des Checkouts ueber 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, waehrend du andere Cookies auf SameSite=Lax belaesst.
• 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 ueber HTTPS gesendet, was dazu fuehrt, dass das Banner erneut erscheint. Stelle sicher, dass deine Seite vollstaendig auf HTTPS laeuft und das Consent-Cookie das Secure-Flag enthaelt.
• Caching-Konflikte: Einige Caching-Plugins cachen die Set-Cookie-Header zusammen mit dem Seiteninhalt. Nachdem du Server-Level-Cookie-Flag-Aenderungen 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 hinzufuegen. Pruefe deine .htaccess, wp-config.php, PHP-ini-Einstellungen und alle Sicherheitsplugins auf ueberlappende Konfigurationen. Verwende den Negative-Lookahead-Regex-Ansatz in der .htaccess, um Duplikate zu vermeiden.

Cookie-Sicherheits-Best-Practices fuer WordPress

• Immer HTTPS verwenden: Das Secure-Flag ist ohne HTTPS bedeutungslos. Stelle sicher, dass deine gesamte Seite ueber HTTPS geladen wird, einschliesslich aller Ressourcen (Bilder, Skripte, Stylesheets). Verwende die FORCE_SSL_ADMIN-Konstante und erwaege einen HSTS-Header, um jeglichen HTTP-Zugriff zu verhindern.
• Standard auf SameSite=Lax setzen: Dies bietet starken CSRF-Schutz, ohne die normale Navigation zu beeintraechtigen. Verwende SameSite=None nur fuer bestimmte Cookies, die genuinen Cross-Site-Zugriff benoetigen, 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 unabhaengig vom Ursprung. Dies ist zuverlaessiger als Plugin-Level- oder PHP-Level-Ansaetze.
• 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 regelmaessig pruefen: Fuehre periodische InspectWP-Scans durch, um neue Cookies zu erkennen, die durch Plugin-Updates oder neue Integrationen eingefuehrt werden. Cookie-Sicherheit ist keine einmalige Massnahme, sondern erfordert fortlaufende Aufmerksamkeit, waehrend 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, waehrend Safari seine eigene Intelligent Tracking Prevention hat, die das Cookie-Verhalten beeinflusst. Teste deine Seite nach Aenderungen auf allen grossen Browsern.