Sicherheits-Ratgeber
Cookie-Sicherheit, verständlich erklärt
Ein Sitzungs-Cookie ist der Schlüssel zu einem Konto, und die Attribute, mit denen es gesetzt wird, entscheiden, wer diesen Schlüssel aufheben kann. Dieser Ratgeber behandelt die Attribute, auf die es ankommt, die Einstellungen für einen typischen Stack und die Grenze zwischen Cookie-Sicherheit und Einwilligung.
01 Warum es wichtig ist
Der Schlüssel zum Konto
Wer ein gültiges Sitzungs-Cookie besitzt, ist für den Server der angemeldete Nutzer. Es braucht kein Passwort und niemand fragt nach einem zweiten Faktor. Damit ist die Art, wie ein Cookie gesetzt wird, mindestens so wichtig wie die Art, wie die Sitzung erzeugt wird: Die Attribute im Set-Cookie-Header entscheiden, ob Skripte es lesen können, ob es über eine unverschlüsselte Verbindung reist und ob eine fremde Seite den Browser dazu bringen kann, es mitzuschicken.
Das ist eine andere Frage als die Cookie-Einwilligung. Bei der Einwilligung geht es darum, ob ein Cookie überhaupt gesetzt werden darf und wofür es genutzt wird. Bei der Cookie-Sicherheit geht es darum, ob die Cookies, die Sie zulässig setzen, gestohlen oder missbraucht werden können. Ein technisch notwendiges Sitzungs-Cookie braucht kein Banner und trotzdem jedes Attribut von dieser Seite.
02 Die Attribute
Sechs Attribute, die über das Risiko entscheiden
Secure
Was es bewirkt. Weist den Browser an, dieses Cookie nur über HTTPS zu senden, niemals über unverschlüsseltes HTTP.
Warum es wichtig ist. Ohne das Attribut genügt eine einzige Anfrage, die auf HTTP rutscht, damit das Cookie im Klartext über die Leitung geht. Das reicht für eine Sitzungsübernahme, und die Anfrage muss keine sein, die der Nutzer bewusst ausgelöst hat.
Set-Cookie: session=abc123; Secure HttpOnly
Was es bewirkt. Versteckt das Cookie vor JavaScript: Es wird mit Anfragen mitgeschickt, aber document.cookie kann es nicht lesen.
Warum es wichtig ist. Es verhindert, dass aus einer Cross-Site-Scripting-Lücke eine Kontoübernahme wird. Ohne HttpOnly kann jedes Skript, das auf die Seite gelangt, auch eines aus einer kompromittierten Fremdbibliothek, die Sitzung auslesen und weiterschicken.
Set-Cookie: session=abc123; Secure; HttpOnly SameSite
Was es bewirkt. Steuert, ob das Cookie bei Anfragen mitreist, die von einer anderen Seite kommen. Lax schickt es nur bei Navigation auf oberster Ebene, Strict nie seitenübergreifend, None immer und verlangt dann Secure.
Warum es wichtig ist. Es ist der eingebaute Schutz gegen Cross-Site-Request-Forgery. Mit Lax kann ein Formular auf einer Angreiferseite den Browser nicht mehr dazu bringen, im Namen des angemeldeten Nutzers etwas zu verändern.
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax Domain / Path
Was es bewirkt. Domain und Path legen fest, an welche Hosts und welche URLs das Cookie geschickt wird. Lässt man Domain weg, bleibt das Cookie auf genau dem Host, der es gesetzt hat.
Warum es wichtig ist. Ein auf die übergeordnete Domain gesetztes Domain-Attribut gibt das Cookie an jede Subdomain weiter, auch an solche, die andere Teams oder ein Hosting-Produkt betreiben, das Sie nicht kontrollieren. Ein enger Geltungsbereich kostet nichts.
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly Max-Age
Was es bewirkt. Max-Age und Expires legen fest, wie lange das Cookie überlebt. Ohne beides ist es ein Sitzungs-Cookie und verschwindet beim Schließen des Browsers.
Warum es wichtig ist. Ein gestohlenes Cookie nützt genau so lange, wie es gültig bleibt. Kurze Laufzeiten plus serverseitiges Entwerten beim Abmelden begrenzen den Schaden, ein Angemeldet-bleiben-Cookie mit einem Jahr Laufzeit tut das Gegenteil.
Set-Cookie: session=abc123; Max-Age=3600; Secure; HttpOnly __Host- Prefix
Was es bewirkt. Ein Cookie, dessen Name mit __Host- beginnt, wird nur akzeptiert, wenn es Secure ist, kein Domain-Attribut trägt und Path=/ nutzt.
Warum es wichtig ist. Damit erzwingt der Browser die Regeln, statt sie der Konvention zu überlassen: Eine Subdomain kann das Cookie nicht durch eine schwächere Fassung überschreiben, weil der Browser alles ablehnt, was die Bedingungen nicht erfüllt.
Set-Cookie: __Host-session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax03 Einrichtung
Das meiste davon ist ein Block Konfiguration
Sitzungs-Cookies setzt Ihre Anwendung, nicht Ihr Webserver. Es ist also eine Änderung an Ihrer Laufzeitkonfiguration und nicht an nginx. In PHP setzen Sie die Sitzungs-Attribute mit ini_set, bevor die Sitzung startet, oder gleichwertig in der php.ini; andere Stacks haben einen entsprechenden Block. Einmal setzen, danach die ausgelieferte Antwort prüfen statt der Konfigurationsdatei.
ini_set( 'session.cookie_secure', '1' );
ini_set( 'session.cookie_httponly', '1' );
ini_set( 'session.cookie_samesite', 'Lax' );
ini_set( 'session.use_strict_mode', '1' );Cookies, die per JavaScript, von einem Consent-Werkzeug oder von einem eingebetteten Drittanbieter gesetzt werden, laufen nicht über diese Konfiguration. Sie brauchen dieselben Attribute an der Stelle, an der sie entstehen, und genau diese findet ein Scan am häufigsten.
04 Fragen
Was zu Cookie-Attributen gefragt wird
Sollte SameSite auf Lax oder Strict stehen?
Lax ist die übliche Antwort, denn Strict verwirft das Cookie auch dann, wenn ein Besucher über einen externen Link kommt, und meldet ihn damit beim Eintreten ab. Strict lohnt sich für Cookies, die nur verändernde Aktionen absichern.
Brauche ich Secure auf einer reinen HTTPS-Website?
Ja. Secure macht die Regel im Browser durchsetzbar, statt sie von Ihren Weiterleitungen abhängig zu machen, und für SameSite=None ist es Pflicht. Es zu setzen kostet nichts.
Ist ein Cookie ohne HttpOnly immer ein Problem?
Nicht immer. Manche Cookies existieren gerade deshalb, damit Skripte sie lesen können, etwa ein CSRF-Token oder eine gespeicherte Themenwahl. Das Attribut zählt bei allem, was einen Nutzer authentifiziert, und darauf zielt ein Befund.
Wie hängt das mit einem Cookie-Banner zusammen?
Es überschneidet sich nicht. Ein Banner regelt die Erlaubnis, ein Cookie überhaupt zu setzen; diese Attribute regeln, wie sicher sich ein Cookie verhält, das Sie setzen dürfen. Die Einwilligungsseite behandelt unser Datenschutz-Ratgeber.
05 Im Detail
Verwandte Sicherheitsthemen
Cookies liegen zwischen Übertragung und Seite. Diese Ratgeber behandeln beide Seiten.
HTTP-Security-Header
Was jeder Response-Header bewirkt, welche Ihre Website senden sollte und wie Sie sie richtig konfigurieren.
Content Security Policy
Der stärkste Schutz gegen Cross-Site-Scripting: welche Direktiven Sie setzen, wie Sie eine Richtlinie im Report-Only-Modus einführen und wie Sie erzwingend werden, ohne Ihre Website zu zerlegen.
HSTS
Strict-Transport-Security erklärt: was max-age, includeSubDomains und preload wirklich bewirken und warum die Preload-Liste eine Entscheidung ist, die Sie nicht schnell zurücknehmen können.
Clickjacking und X-Frame-Options
Wie eine unsichtbare Überlagerung aus einem Besucherklick eine Aktion auf Ihrer Website macht, und die zwei Header, die das verhindern: X-Frame-Options für ältere Clients, frame-ancestors für alles andere.
Referrer-Policy
Welcher Teil Ihrer URLs an fremde Seiten geht, wenn ein Besucher weiterklickt: die fünf Werte, die zählen, was jeder davon preisgibt und welcher der sinnvolle Standard ist.
Permissions-Policy
Kamera, Mikrofon, Standort und Bezahlfunktion für Ihre Website und alle eingebetteten Inhalte abschalten: die Syntax der Positivliste und warum eine nicht genannte Funktion keine abgeschaltete Funktion ist.
SPF, DMARC und DNSSEC
Die Einträge, die verhindern, dass jemand in Ihrem Namen Mails verschickt, und der, der Ihre DNS-Antworten ehrlich hält: was jeder leistet und in welcher Reihenfolge Sie sie einführen.
security.txt
Die Datei, die Sicherheitsforschern sagt, wohin eine Schwachstelle gemeldet wird. Zwei Pflichtfelder, zehn Minuten Arbeit, und der Unterschied zwischen einer privaten und einer öffentlichen Meldung.
Security-Header überwachen
Ein Header, der heute stimmt, kann nach dem nächsten Deploy fehlen. Drei Wege, das zu bemerken: ein Cronjob mit curl, eine Prüfung in Ihrer CI-Pipeline und ein geplanter Scan, jeweils mit dem, was er findet und was nicht.
CSP-Änderungen erkennen
Wie sich eine Richtlinie durch Deploys, Plugins und CDN-Regeln unbemerkt ändert und wie Sie es merken: ein Header-Diff, Verstoßmeldungen über report-to und was ein Scan-Vergleich zeigen kann und was nicht.
Weiterlesen
Weitere Ratgeber
Jeder Ratgeber steht für sich, zusammen decken sie ab, worauf unser Scanner schaut. Wählen Sie den, der Ihrer nächsten Frage am nächsten kommt.
Sehen Sie, wie Ihre Cookies gesetzt werden
Unser kostenloser Quickscan liest die Attribute Secure, HttpOnly und SameSite jedes Cookies, das Ihre Website setzt, zusammen mit Ihren Security-Headern und Datenschutz-Signalen.