Cookie-Sicherheitsanalysator

Jedes Sitzungs- oder Authentifizierungs-Cookie sollte folgende Attribute haben: (1) HttpOnly — verhindert JavaScript-Zugriff und blockiert XSS-Cookie-Diebstahl; (2) Secure — stellt sicher, dass das Cookie nur über HTTPS gesendet wird und verhindert Abfangen; (3) SameSite=Strict oder Lax — verhindert CSRF-Angriffe, indem eingeschränkt wird, wann Cookies cross-site gesendet werden. Bei nicht-sensiblen Cookies (Analytics, Einstellungen) können entspanntere Einstellungen akzeptabel sein, aber sicherheitskritische Cookies (Sitzungs-IDs, Auth-Tokens) sollten immer alle drei haben.

SameSite steuert, wann ein Cookie bei Cross-Site-Anfragen gesendet wird. Strict: wird nur bei Same-Site-Anfragen gesendet (am sichersten, kann aber OAuth-Flows und Links aus E-Mails beeinträchtigen). Lax (Standard in modernen Browsern): wird bei Top-Level-Navigation, aber nicht bei Cross-Site-API-Anfragen gesendet. None: wird bei allen Cross-Site-Anfragen gesendet — erfordert das Secure-Flag. Verwenden Sie Strict für Auth/Sitzungs-Cookies, Lax für die meisten anderen, None nur für Drittanbieter-Cookies, die cross-site funktionieren müssen (z. B. eingebettete Widgets, SSO).

Sitzungs-Cookies haben kein Expires- oder Max-Age-Attribut — sie werden gelöscht, wenn die Browser-Sitzung endet (Nutzer schließt Browser-Tab/Fenster). Persistente Cookies haben ein Expires-Datum oder einen Max-Age-Wert und überleben Browser-Neustarts. Für die Authentifizierung sind Sitzungs-Cookies sicherer (kürzeres Expositionsfenster), können aber für "Angemeldet bleiben"-Funktionen unbequem sein. Langlebige persistente Cookies sind risikoreicher — wenn sie gestohlen werden, bleiben sie länger gültig.

Browser schaffen Drittanbieter-Cookies (Cookies mit einem Domain-Attribut, das sich von der Domain der Seite unterscheidet) aus Datenschutzgründen ab. Chrome bewegt sich von Drittanbieter-Cookies weg, Safari und Firefox blockieren sie bereits standardmäßig. Wenn Ihre Cookies ein Domain-Attribut haben, das auf eine andere Domain gesetzt ist, werden sie bei Cross-Site-Anfragen blockiert. Moderne Authentifizierungsmuster verwenden Same-Site-Alternativen wie OAuth-Redirect-Flows, Token-basierte Auth oder Browser-partitionierten Speicher.

Der Analyzer ruft die URL ab und inspiziert Set-Cookie-Header in der HTTP-Antwort. Cookies, die von JavaScript (document.cookie) nach dem Seitenladen gesetzt werden, sind nicht sichtbar, da das Tool nur serverseitige Cookies sieht. Außerdem setzen einige Anwendungen Cookies nur nach der Anmeldung oder bei bestimmten Aktionen — das Testen einer Login-Seiten-URL kann andere Cookies zeigen als die Startseite. Für umfassendes Cookie-Auditing verwenden Sie Browser-DevTools und protokollieren Sie alle Set-Cookie-Header im gesamten Nutzer-Flow.