Prüfpunkt software.cookie.ohne_schutzSitzung, Cookies und Zahlungsdaten
Welche Merkmale schützen die Cookies Ihrer Website?
Ein Cookie ist ein kleiner Eintrag, den Ihr Server im Browser des Besuchers ablegt, etwa die Kennung einer Anmeldung oder eines Warenkorbs. Drei Merkmale legen fest, wie der Browser damit umgeht: Secure schickt es nur über verschlüsselte Verbindungen, HttpOnly verbirgt es vor Skripten, SameSite regelt, ob andere Websites es mitsenden lassen. Die Prüfung erwartet alle drei an jedem Cookie, das Ihr Server setzt, und nennt im Bericht die Namen der Cookies, denen eines fehlt.
Ein gestohlenes Sitzungscookie ersetzt die Anmeldung

Die Sicherheitsorganisation OWASP setzt eine laufende Sitzung mit der stärksten Anmeldung gleich, die Ihre Website kennt, auch mit einer zweiten Bestätigung. Die EU-Agentur ENISA beschreibt für 2025 Schadprogramme, die Sitzungscookies stehlen und so Konten übernehmen. Die drei Merkmale wirken im Netz und im Browser, nicht auf einem befallenen Gerät. Dort begrenzt eine kurze Sitzung den Schaden.
Das Sitzungscookie ist der Schlüssel zum Konto
Nach der Anmeldung erkennt Ihre Website einen Besucher an einem Cookie. Wer dieses Cookie kennt, ist für die Website derselbe Besucher, ohne Passwort. Deshalb schützen die drei Merkmale vor allem Anmeldungen, Kundenkonten und Warenkörbe. Secure verhindert, dass das Cookie über eine unverschlüsselte Verbindung mitgeschickt und im selben WLAN mitgelesen wird. HttpOnly sorgt dafür, dass ein eingeschleustes Skript es nicht auslesen und weitergeben kann. SameSite hält den Browser davon ab, das Cookie mitzuschicken, wenn eine fremde Website im Hintergrund eine Anfrage an Ihre Website auslöst, etwa um ein Formular in Ihrem Namen abzuschicken.
Gemessen wird die Kopfzeile Set-Cookie
Die Prüfung liest in der Antwort jeder Seite des Laufs, die über https lädt, die Kopfzeilen Set-Cookie. Fehlt einem Cookie eines der drei Merkmale Secure, HttpOnly oder SameSite, steht es im Befund; der Bericht nennt bis zu fünf Namen und zeigt die Kopfzeilen, wie Ihr Server sie geschickt hat. Gemessen werden die Cookies, die der Server setzt. Cookies, die ein Skript erst im Browser anlegt, etwa von Statistikdiensten, erscheinen nicht in dieser Kopfzeile und zählen hier nicht.
SameSite: Lax für die meisten Cookies
SameSite kennt drei Werte. Strict schickt das Cookie nur bei Anfragen von Ihrer eigenen Website mit; wer über einen Link von einer anderen Website kommt, etwa aus einem Webmail, ist dann beim ersten Aufruf nicht angemeldet. Lax schickt es zusätzlich, wenn jemand einem Link zu Ihrer Seite folgt, aber nicht bei POST-Formularen oder Anfragen, die eine fremde Seite im Hintergrund auslöst. Für die meisten Websites ist Lax die passende Wahl. None schickt das Cookie überall mit und ist nur zusammen mit Secure erlaubt, etwa für eingebettete Inhalte auf fremden Seiten. Fehlt die Angabe, entscheidet der Browser selbst, und die Browser handhaben das unterschiedlich.
Die Einstellung liegt im System Ihrer Website
Welche Merkmale ein Cookie hat, legt die Software fest, die es setzt: das Content-Management-System, der Shop, eine Erweiterung oder der Webserver. Bei verbreiteten Systemen ist es oft eine Einstellung der Sitzung oder eine Zeile in der Server-Konfiguration. Ein Cookie, das ein Skript Ihrer Seite selbst lesen muss, etwa für die Anzeige im Browser, kann HttpOnly nicht haben; Secure und SameSite gelten dort trotzdem. Nach der Änderung zeigt eine neue Messung, welche Cookies noch ein Merkmal brauchen.
Beispiele
Sitzungscookie
Set-Cookie: sitzung=4f9a2c7e; Path=/Set-Cookie: sitzung=4f9a2c7e; Path=/; Secure; HttpOnly; SameSite=LaxName und Wert bleiben gleich; die drei Merkmale stehen am Ende der Zeile.
So gehen Sie es an
- Lassen Sie Ihre Agentur die Cookie-Namen aus dem Bericht zuordnen: welches System setzt welches Cookie, und wozu dient es?
- Für jedes Cookie, das eine Anmeldung, ein Konto oder einen Warenkorb enthält, setzt sie Secure, HttpOnly und SameSite=Lax.
- Bei Cookies, die ein Skript Ihrer Seite lesen muss, bleiben Secure und SameSite; HttpOnly entfällt dort.
- Prüfen Sie danach Anmeldung, Warenkorb und Bezahlung einmal von Hand, auch über einen Link von einer anderen Website.
- Lassen Sie die Website neu messen. Der Bericht zeigt die Kopfzeilen Set-Cookie, wie Ihr Server sie jetzt schickt.
Tipps aus der Praxis
- Das Präfix __Host- im Cookienamen verlangt Secure, Path=/ und keine Domain-Angabe. Ein Browser, der Präfixe kennt, weist ein anders gesetztes Cookie ab.
- Lassen Sie die Domain-Angabe weg, wenn keine Unterdomäne das Cookie braucht. Dann bekommt es nur die Adresse zurück, die es gesetzt hat.
- Fragen Sie, ob das System nach der Anmeldung eine neue Sitzungskennung vergibt. OWASP verlangt das.
Mehr zu diesem Thema
Weiter in der Cybersicherheit
- Wie wird eine kleine Website angegriffen?Bekannte Lücken, Anmeldung, Fehlkonfiguration, fremde Skripte: die Wege in kleine Websites nach BSI, ENISA, Verizon und Patchstack. Woran Sie jeden erkennen.
- Was kann ein Angriff auf meiner Website anrichten?Kartendaten aus dem Bestellformular, Besucher auf Betrugsseiten, 20 Millionen Pfund Bußgeld: echte Fälle mit Quelle und dem Merkmal, das den Weg zeigt.
- Wann schützt eine Content-Security-Policy vor eingeschleusten Skripten?Eine Content-Security-Policy legt fest, welche Skripte der Browser ausführt. Sie wirkt, wenn sie Skripte einzeln freigibt statt pauschal.
- Wehrt Ihre Website das Abtasten nach Schwachstellen ab?Am Ende der Prüfung ruft der Messkern typische Scan-Adressen ab und sieht nach, ob Ihr Server danach sperrt. Das Ergebnis steht als Hinweis im Bericht.
Dieser Prüfpunkt gehört zur Cybersicherheit, Unterthema Sitzung, Cookies und Zahlungsdaten. Gemessen wird er im Prüfbereich Aktualität. Was die Prüfung insgesamt leistet, zeigt die Leistungsseite; wie ein Ergebnis zustande kommt, erklärt das Prüfverfahren.




