Cookie-Sicherheit: Attribute passend zum Zweck setzen

Was Sie an einem Cookie prüfen können

Ein Cookie kann beispielsweise eine Spracheinstellung speichern oder einen Verweis auf eine serverseitige Anmeldung enthalten. Aus seinem Namen allein lässt sich weder sein Inhalt noch seine Bedeutung für die Anmeldung sicher ableiten. Klären Sie deshalb zuerst, welche Stelle den Cookie setzt und wofür die Anwendung ihn verwendet.

Ein Set-Cookie-Header zeigt, was der Server dem Browser übermittelt. Ob der Browser den Cookie annimmt, wie lange er ihn behält und bei welcher späteren Anfrage er ihn sendet, sind weitere Fragen. Zusätzliche Browserregeln und Nutzereinstellungen können die Speicherung oder den Versand einschränken. MDN: Cookies verwenden

Der Web Security Check analysiert Cookieattribute in den beobachteten Set-Cookie-Headern einer abgerufenen Antwort. Er führt keinen Login durch und erfasst weder alle Pfade noch später per JavaScript gesetzte Cookies oder den vollständigen Browserbestand. Ein nicht beobachteter Cookie ist damit weder als fehlend noch als sicher bestätigt. Ein einzelner Befund kann dennoch Ihre erste Konfigurationsfrage beantworten.

Secure, HttpOnly und SameSite haben verschiedene Aufgaben

Bei Secure behandeln manche Browser lokale Entwicklungsadressen besonders. Solche Ausnahmen sind keine Grundlage für eine öffentliche HTTP-Konfiguration. Für produktive Webanwendungen muss die HTTPS-Auslieferung einschließlich vorgeschalteter Proxys zur Cookiekonfiguration passen. MDN: Set-Cookie

Für einen serverseitig verwendeten, nur an einen Host gebundenen Sessioncookie kann beispielsweise folgende Kombination passen:

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

Der Wert ist erfunden, das Beispiel nicht praktisch getestet. Es setzt HTTPS, einen unterstützenden Browser und einen Ablauf voraus, der mit Lax funktioniert. __Host- verlangt zusätzlich zum sicheren Setzen ausdrücklich Path=/ und verbietet ein Domain-Attribut. Das Präfix ersetzt weder HttpOnly noch die bewusste Wahl von SameSite. Das weniger einschränkende __Secure- verlangt in unterstützenden Browsern ebenfalls sicheres Setzen mit Secure, aber keine zusätzliche Host-/Pfadbindung wie __Host-. Ein allgemeiner Schutz vor Cookie-Jar-Overflow folgt aus diesen Präfixen nicht.

Site, Host und Pfad auseinanderhalten

Für gewöhnliche HTTP(S)-Adressen richtet sich „same-site“ nach dem Schema und der registrierbaren Domain. Die Grenze ergibt sich nicht immer allein aus dem letzten Punkt im Namen: Die Public Suffix List berücksichtigt auch bestimmte Hostingangebote.

https://app.example.com und https://api.example.com sind same-site, aber verschiedene Origins. Ein Origin wird durch Schema, Host und Port bestimmt. Ein Wechsel von HTTPS zu HTTP kann deshalb cross-site sein, während ein anderer Port bei gleichem Schema und gleicher registrierbarer Domain die Site nicht ändert. Eine kompromittierte Geschwisterdomain wird durch SameSite somit nicht grundsätzlich ausgeschlossen. web.dev: Same-site und same-origin

Path ist keine verlässliche Sicherheitsgrenze zwischen Anwendungen auf demselben Host. Domain- und Pfadangaben entscheiden auch mit darüber, welchen vorhandenen Cookie Sie ändern oder löschen. RFC 6265: Domain und Path

SameSite wählen und seine CSRF-Grenze verstehen

Cross-Site Request Forgery nutzt unter anderem aus, dass der Browser einer von außen ausgelösten Anfrage vorhandene Anmeldeinformationen beifügen kann. Ob eine Anwendung daraufhin eine Aktion ausführt, hängt zusätzlich von ihrer Authentisierung, Autorisierung und CSRF-Prüfung ab.

Die folgende Tabelle beschreibt ausschließlich die SameSite-Bedingung. Sie setzt voraus, dass der Cookie bereits gespeichert ist, Domain und Pfad passen und keine andere Browserregel den Versand verhindert.

„Sichere HTTP-Methode“ ist ein Protokollbegriff, kein Urteil über die Sicherheit Ihrer Anwendung. Zustandsänderungen gehören nicht in einen GET-Abruf. Auch mit Lax bleiben zusätzliche CSRF-Gegenmaßnahmen erforderlich. Ein fehlendes SameSite-Attribut ist nicht gleichbedeutend mit None: Browser können einen Lax-Standard anwenden; eine weniger strenge Variante kann bei kürzlich gesetzten Cookies bestimmte Top-Level-POSTs zulassen. Verlassen Sie sich nicht auf diesen Übergangsfall. 6265bis-22: SameSite-Verarbeitung

Für Login-, Zahlungs- und Einbettungsabläufe ist der Unterschied praktisch relevant. Bei einem externen Link wird ein Strict-Cookie bei der ersten Cross-Site-Navigation nicht mitgeschickt. Das bedeutet nicht automatisch, dass die serverseitige Sitzung beendet oder eine erneute Anmeldung erforderlich ist. None; Secure kann für bewusst benötigte Cross-Site-Funktionen passen, setzt Browserbeschränkungen für Drittanbieter-Cookies aber nicht außer Kraft.

Laufzeit und Abmeldung getrennt prüfen

Max-Age setzt eine Lebensdauer in Sekunden; Expires nennt einen Zeitpunkt. Sind beide vorhanden, hat Max-Age Vorrang. Ein Browser kann einen Cookie schon vorher entfernen, etwa aufgrund seiner Speicherregeln oder einer Nutzeraktion.

Fehlen beide Angaben, handelt es sich um einen Sessioncookie im Sinne der Browserspeicherung. Wann eine Browsersitzung endet, bestimmt der Browser; eine Sitzungswiederherstellung kann Cookies nach einem Neustart weiterverwenden. Der Eintrag „Session“ beweist deshalb weder einen garantierten Löschzeitpunkt noch eine gültige Anmeldung.

Zum Entfernen eines Cookies muss die Anwendung den passenden Namen sowie die passende Domain-/Hostbindung und den Pfad treffen, beispielsweise mit Max-Age=0. Die serverseitige Anwendungssitzung muss beim Logout zusätzlich ungültig werden. Das Löschen im Browser allein entwertet keinen bereits kopierten Sessionbezeichner. MDN: Cookies entfernen, OWASP: Session Management

Konfiguration in drei Schritten bearbeiten

1. Den benötigten Ablauf und die zuständige Stelle bestimmen

Erfassen Sie Cookiezweck, setzende Anwendung, benötigte Hosts/Pfade, Laufzeit und Zugriff durch JavaScript. Prüfen Sie besonders externe Anmeldungen, Zahlungsrückleitungen und eingebettete Inhalte. Ein serverseitig verwendeter Sessioncookie kann HttpOnly erhalten; ein absichtlich durch JavaScript gelesenes Einstellungscookie braucht eine andere Entscheidung.

Setzen Sie die Attribute möglichst dort, wo der Cookie entsteht. Ein Reverse Proxy kann Attribute von Upstream-Cookies ergänzen, kennt aber nicht automatisch deren Anwendungszweck.

2. Gezielte Cookieoptionen setzen

Das folgende Nginx-Fragment verändert den vom Upstream gesetzten Cookie namens session. Es benötigt proxy_cookie_flags ab Nginx 1.19.3 und einen passenden Proxykontext:

location / {
    proxy_pass http://backend;
    proxy_cookie_flags session secure httponly samesite=lax;
}

backend ist ein Platzhalter für Ihren eingerichteten Upstream. Das Fragment ist nicht ausgeführt. Es ändert weder den Cookie-Namen noch automatisch Domain, Path oder Laufzeit und erfasst keine später im Browser erzeugten Cookies. Bei mehreren Regeln gilt die erste zutreffende; prüfen Sie auch geerbte Konfiguration. Übertragen Sie eine SameSite-Regel nicht ungeprüft auf sämtliche Cookies. Nginx: proxy_cookie_flags

Für eine bereits eingerichtete express-session-Middleware können Sie folgende Optionen als cookie-Option verwenden:

const cookieOptions = {
  secure: true,
  httpOnly: true,
  sameSite: 'lax',
  path: '/',
};

Das ist nur das Cookieoptionsobjekt, keine vollständige Express-Anwendung. Secret, Sessionstore und übrige Middlewarekonfiguration sind hier nicht enthalten. Mit secure: true muss die Anwendung die Anfrage als HTTPS erkennen. Hinter einem Reverse Proxy muss dessen Vertrauenskonfiguration zum tatsächlichen Aufbau passen; eine pauschale Proxyfreigabe ist keine sichere Standardlösung. Auch dieses Beispiel ist nicht praktisch getestet. Express: express-session

3. Antwort und Browserablauf erneut prüfen

Für einen ersten Blick auf die Header einer GET-Antwort können Sie auf einem berechtigten Ziel beispielsweise verwenden:

curl -sS -D - -o /dev/null https://example.com/login

Die Adresse ist ein Platzhalter. Dieser nicht ausgeführte Aufruf führt keinen Login durch, folgt keiner Weiterleitung und bildet keine Browser-Cookieregeln ab. Ein HEAD-Abruf mit -I ist eine andere Anfrage; seine Antwort muss nicht dieselben Cookies setzen. Prüfen Sie die Antwort, in der der relevante Cookie tatsächlich entsteht, etwa nach einem berechtigten Login. curl: dokumentierte Optionen

Kontrollieren Sie anschließend im Browser gespeicherte Attribute, Blockiergründe und die Cookies einer späteren Anfrage. Vergleichen Sie auch Abmeldung und betroffene externe Abläufe.

Einen technischen Befund nachvollziehbar dokumentieren

Halten Sie Cookiezweck, betrachteten Ablauf, Browserkontext, beobachtete Attribute, offene Fragen und erneute Prüfung fest. Sessionwerte gehören nicht in eine öffentliche Übergabedokumentation. Die Attribute können technische Schutzmaßnahmen unterstützen; sie belegen weder vollständige Sicherheit noch Rechtmäßigkeit oder DSGVO-Konformität.

Ob und welche Anforderungen aus PCI DSS, NIS2 oder anderen Vorgaben im konkreten Fall gelten, ist getrennt zu beurteilen. Ein Cookiecheck ist dafür kein vollständiger Nachweis. Aus technischen Einstellungen lässt sich insbesondere nicht allein entscheiden, ob ein Cookie eine Einwilligung benötigt.

Passende Vertiefung und Konfigurationswege

Wenn eine öffentliche Antwortprüfung Ihre nächste Frage klärt, können Sie den Web Security Check öffnen. Die oben beschriebenen Login- und Browserprüfungen bleiben ein eigener Schritt.