Kurz eingeordnet
Nicht jedes fehlende Cookie-Attribut hat dieselbe Dringlichkeit
Entscheidend ist der Einsatzzweck. Ein Cookie kann eine Anmeldung absichern, eine anonyme Sitzung zusammenhalten, Einstellungen speichern oder lediglich eine technische Hilfsfunktion übernehmen. Der Name des Cookies liefert dafür manchmal einen Hinweis, aber noch keinen sicheren Nachweis.
- Secure: bei Login- und Sitzungs-Cookies eine wichtige Schutzmaßnahme für die Übertragung
- HttpOnly: relevant, wenn JavaScript den Cookie nicht lesen können soll
- SameSite: sinnvolle zusätzliche Härtung gegen unerwünschte Cross-Site-Anfragen
Ein technischer Scan kann erkennen, welche Attribute im HTTP-Header vorhanden sind. Er kann ohne zusätzlichen Kontext aber nicht zuverlässig bestimmen, welche serverseitige Funktion oder welche Daten mit der Cookie-Kennung verbunden sind.
Attribut 1
Secure schützt die Übertragung über HTTPS
Mit dem Attribut Secure sendet der Browser einen Cookie nur über eine verschlüsselte HTTPS-Verbindung. Das ist besonders wichtig, wenn der Cookie eine Anmeldung oder Sitzung identifiziert. Ohne dieses Attribut kann ein Browser den Cookie unter bestimmten Bedingungen auch bei einer unverschlüsselten Anfrage mitsenden.
Eine konsequente HTTPS-Weiterleitung und HSTS reduzieren das Risiko zusätzlich, ersetzen das Cookie-Attribut aber nicht. Die Schutzwirkung sollte direkt am Cookie festgelegt werden.
OWASP empfiehlt Secure ausdrücklich für Sitzungs-Cookies: Session Management Cheat Sheet .
Attribut 2
HttpOnly begrenzt den Zugriff durch JavaScript
HttpOnly verhindert, dass JavaScript den Cookie über document.cookie ausliest. Das ist bei Sitzungskennungen eine wichtige zusätzliche Schutzschicht, falls auf einer Website eine Cross-Site-Scripting-Schwachstelle ausgenutzt wird.
Das Attribut verhindert nicht, dass der Browser den Cookie bei regulären HTTP-Anfragen automatisch mitsendet. Es ersetzt deshalb weder die Absicherung gegen Cross-Site-Scripting noch eine passende SameSite-Konfiguration.
Attribut 3
SameSite steuert Cross-Site-Anfragen
SameSite legt fest, ob ein Cookie bei Anfragen mitgesendet wird, die von einer anderen Website ausgehen. Das unterstützt unter anderem den Schutz gegen Cross-Site Request Forgery. Moderne Browser behandeln eine fehlende SameSite-Angabe meist wie Lax. Eine explizite Konfiguration bleibt trotzdem sinnvoll, weil sie das gewünschte Verhalten eindeutig festlegt.
Lax: praktikabler Standard für viele Sitzungs-Cookies; die meisten Cross-Site-Anfragen erhalten den Cookie nicht.
Strict: stärkere Einschränkung, die gewünschte Abläufe nach externen Links beeinflussen kann.
None: erlaubt Cross-Site-Nutzung und ist nur zusammen mit Secure zulässig.
Mozilla dokumentiert die Browserregeln und Konfigurationsbeispiele im Leitfaden Secure cookie configuration .
Datenschutzbezug
Ein fehlendes Attribut ist nicht automatisch ein DSGVO-Verstoß
Artikel 32 DSGVO verlangt ein Schutzniveau, das zum tatsächlichen Risiko der Verarbeitung passt. Deshalb hängt die Datenschutzrelevanz davon ab, ob der Cookie eine Person oder eine schützenswerte Sitzung identifiziert und welche Folgen ein unbefugter Zugriff hätte.
Bei einer authentifizierten Kunden- oder Administrationssitzung ist fehlendes Secure deutlich relevanter als bei einer anonymen Komfortfunktion. Eine fehlende explizite SameSite-Angabe ist häufig zusätzliche technische Härtung. Der einzelne Header-Befund reicht für eine abschließende rechtliche Bewertung nicht aus.
Den risikobasierten Maßstab beschreibt Artikel 32 DSGVO .
Scanner richtig lesen
Mehrere Antworten können denselben Fehler wiederholen
Setzt eine Website denselben Cookie auf mehreren Unterseiten immer wieder mit derselben Konfiguration, entsteht technisch eine Fundstelle pro HTTP-Antwort. Für einen verständlichen Bericht sollten diese Wiederholungen zu einem Konfigurationsbefund zusammengeführt werden.
Die Zahl elf beschreibt die technische Verbreitung auf den geprüften Seiten. Sie bedeutet nicht, dass elf unterschiedliche Cookie-Probleme vorliegen. Auch der Bestandteil „sid“ kann auf eine Sitzungskennung hindeuten, beweist ihren genauen Zweck aber nicht.
Eine gute Handlungsempfehlung beginnt deshalb mit der Prüfung des Einsatzzwecks. Erst danach lässt sich entscheiden, welche Attribute erforderlich sind und wie dringend die Änderung ist.
Sinnvolle Umsetzung
Zuerst den Zweck klären, dann passend konfigurieren
SameSite=None sollte keine pauschale Ausweichlösung sein. Es ist nur sinnvoll, wenn eine echte Cross-Site-Funktion benötigt wird, und setzt immer Secure voraus.
Häufige Fragen
Cookie-Schutzattribute in Website-Scans
Ist ein Cookie ohne Secure automatisch ein DSGVO-Verstoß?
Nein. Die Bedeutung hängt vom Zweck und den damit verbundenen Daten oder Sitzungen ab. Für Login- und Sitzungs-Cookies ist Secure aber eine wichtige technische Schutzmaßnahme.
Ist SameSite noch nötig, wenn Browser standardmäßig Lax verwenden?
Eine explizite Konfiguration bleibt sinnvoll. Sie dokumentiert das beabsichtigte Verhalten und sorgt für eine verlässlichere Behandlung über Browser und Versionen hinweg.
Sind elf Fundstellen desselben Cookies elf unterschiedliche Fehler?
Normalerweise nicht. Wird derselbe Cookie in mehreren Antworten gleich gesetzt, sollte der Bericht diese Vorkommen als einen wiederholten Konfigurationsbefund zusammenfassen.