Was sind Cookie-Sicherheitsflags?

Jedes Mal, wenn deine WordPress-Seite ein Cookie setzt (ob für Login-Sessions, Warenkörbe, Analytics oder Consent-Einstellungen), kann dieses Cookie eine Reihe von Sicherheitsflags mitbringen. Diese Flags sagen dem Browser, wie er mit dem Cookie umgehen soll: wann er es senden darf, wer es lesen kann und über welche Verbindungen es übertragen werden darf. Falsche Einstellungen machen nichts sichtbar kaputt, aber sie öffnen die Tür für Angriffe, die die meisten Seitenbetreiber erst bemerken, wenn es zu spät ist.

Das Secure-Cookie-Flag: Cookies nur über HTTPS

Ein Cookie mit dem Secure-Flag wird nur über HTTPS-Verbindungen übertragen. Der Browser weigert sich schlicht, es in unverschlüsselte HTTP-Anfragen einzubauen.

Set-Cookie: session_id=abc123; Secure

Warum ist das wichtig? Stell dir einen Besucher vor, der deine Seite im WLAN eines Cafés aufruft. Falls er eine Seite über unverschlüsseltes HTTP lädt (vielleicht über ein altes Lesezeichen oder eine fehlerhafte Weiterleitung), würden seine Cookies normalerweise im Klartext durchs Netzwerk wandern. Jeder, der den WLAN-Traffic mitschneidet, könnte das Session-Cookie abgreifen und den Nutzer imitieren. Mit dem Secure-Flag hält der Browser das Cookie in diesem Szenario komplett zurück.

Da deine WordPress-Seite ohnehin auf HTTPS laufen sollte (und das sollte sie, dafür gibt es 2025 keine Ausrede mehr), kostet dieses Flag nichts und verhindert eine reale Angriffsklasse.

Das HttpOnly-Cookie-Flag: Schutz gegen XSS-Angriffe

Das HttpOnly-Flag verhindert, dass JavaScript über document.cookie auf das Cookie zugreifen kann. Das Cookie wird weiterhin ganz normal mit HTTP-Anfragen gesendet, aber kein clientseitiges Skript kann es lesen oder manipulieren.

Set-Cookie: session_id=abc123; HttpOnly

Dieses Flag existiert speziell, um den Schaden von Cross-Site-Scripting-Angriffen (XSS) zu begrenzen. Wenn es einem Angreifer gelingt, JavaScript in deine Seite einzuschleusen (über ein verwundbares Plugin, ein Kommentarfeld oder einen gespeicherten XSS-Vektor), wird dieses Skript als erstes document.cookie aufrufen, um Session-Tokens zu stehlen. Mit HttpOnly liefert dieser Aufruf für die geschützten Cookies nichts zurück.

Das verhindert XSS selbst nicht. Es behebt nicht die zugrunde liegende Schwachstelle. Aber es nimmt den wertvollsten Preis (Session-Cookies) vom Tisch, und das macht oft den Unterschied zwischen einer Lästigkeit und einer vollständigen Account-Übernahme.

Das SameSite-Cookie-Flag: Schutz gegen CSRF

Das SameSite-Attribut steuert das Cross-Site-Verhalten von Cookies. Es bestimmt, ob der Browser ein Cookie sendet, wenn eine Anfrage von einer anderen Domain stammt als der, die es gesetzt hat.

Es gibt drei mögliche Werte:

• SameSite=Strict: Das Cookie wird nie mit Cross-Site-Anfragen gesendet. Punkt. Wenn jemand von einer externen Seite auf einen Link zu deiner Seite klickt, wird das Session-Cookie bei dieser ersten Anfrage nicht mitgesendet. Das ist die restriktivste Einstellung und kann Usability-Probleme verursachen (Nutzer erscheinen ausgeloggt, wenn sie über externe Links kommen).
• SameSite=Lax: Das Cookie wird bei Top-Level-Navigationen (Klick auf einen Link) gesendet, aber nicht bei eingebetteten Anfragen wie Bildern, iFrames oder Formular-Einsendungen von anderen Seiten. Das ist der Browser-Standard seit Chrome 80 (2020) und bietet eine gute Balance zwischen Sicherheit und Benutzerfreundlichkeit.
• SameSite=None: Das Cookie wird mit allen Anfragen gesendet, unabhängig vom Ursprung. Das braucht man für legitime Third-Party-Cookie-Anwendungsfälle (eingebettete Zahlungsformulare, SSO, Werbung), muss aber immer mit dem Secure-Flag kombiniert werden, da Browser SameSite=None ohne Secure ablehnen.

Set-Cookie: session_id=abc123; SameSite=Lax

Die Hauptbedrohung, die SameSite adressiert, ist Cross-Site Request Forgery (CSRF), Angriffe, bei denen eine bösartige Seite deinen Browser dazu bringt, authentifizierte Anfragen an deine WordPress-Seite zu stellen, ohne dass du es merkst.

Empfohlene sichere Cookie-Konfiguration

Für Authentifizierungs- und Session-Cookies lautet die empfohlene Konfiguration:

Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Lax; Path=/

Jedes Flag deckt einen anderen Angriffsvektor ab:

• Secure: stoppt Abfangen auf Netzwerkebene
• HttpOnly: stoppt Diebstahl auf Skriptebene (XSS)
• SameSite: stoppt Cross-Origin-Missbrauch (CSRF)

Fehlt eines davon, bleibt eine Lücke. Sie funktionieren als Team.

Third-Party-Cookie-Sicherheit und DSGVO

Cookies, die von externen Diensten auf deiner Seite gesetzt werden (Analytics, Chat-Widgets, Werbepixel), liegen außerhalb deiner direkten Kontrolle. Ihre Sicherheitsflags werden vom jeweiligen Dienst bestimmt. Aber du solltest sie kennen. Ein Third-Party-Cookie ohne Secure oder mit SameSite=None schafft Angriffsfläche auf deiner Domain, auch wenn du das Cookie nicht selbst gesetzt hast.

Das ist besonders für die DSGVO-Konformität relevant: zu wissen, welche Cookies auf deiner Seite gesetzt werden und wie sie konfiguriert sind, gehört zu deiner Verantwortung als Seitenbetreiber.

Cookie-Sicherheitsflags prüfen mit InspectWP

InspectWP untersucht jedes Cookie, das beim Laden einer Seite auf deiner WordPress-Seite gesetzt wird, und markiert alle, bei denen die Secure-, HttpOnly- oder SameSite-Attribute fehlen. Der Bericht zeigt jedes Cookie mit seinen aktuellen Flags, damit du schnell siehst, welche Aufmerksamkeit brauchen, egal ob sie von WordPress Core, Plugins oder Third-Party-Skripten stammen.