Cookie-Security-Checker

Drei Flags entscheiden, ob eine Session gestohlen werden kann.

Gib eine URL ein und wir listen die Cookies auf, die deine Seite setzt, und prüfen jedes auf Secure, HttpOnly und SameSite. Session-Cookies sind der Zugang, den deine Nutzer nie sehen, und diese drei Attribute sind der größte Teil ihres Schutzes.

Was hier geprüft wird, und wie eine gute Antwort aussieht

Secure

Ohne dieses Flag schickt der Browser das Cookie auch über einfaches http und nicht nur über https. Das klingt theoretisch, bis man sich erinnert, wie es wirklich passiert: eine Nutzerin tippt deine Domain ohne Schema, oder klickt auf einen alten http-Link, der Browser macht eine unverschlüsselte Anfrage, bevor deine Weiterleitung greift, und das Session-Cookie reist im Klartext über das Netz mit, in dem sie gerade ist. Die Weiterleitung rettet dich nicht, denn das Cookie war schon unterwegs. Jedes Cookie, das einen Nutzer identifiziert, braucht das.

HttpOnly

Ohne dieses Flag kann document.cookie den Wert lesen, und damit kann es jedes Skript auf der Seite. Das ist der ganze Gewinn eines Cross-Site-Scripting-Bugs: der Angreifer muss nichts Cleveres mehr tun, sobald er das Session-Cookie lesen kann, er nimmt es und wird zu diesem Nutzer. Mit gesetztem HttpOnly bleibt derselbe Bug ein Bug, aber die Session überlebt ihn. Dieses Flag entscheidet, wie teuer dein nächstes XSS wird.

SameSite

Ob das Cookie an Anfragen angehängt wird, die von anderen Seiten kommen. Ohne gesetzten Wert kann ein Formular auf der Seite eines Fremden an deinen Endpoint senden, und der Browser legt die Session hilfsbereit dazu, was Cross-Site Request Forgery ist. Lax ist die vernünftige Voreinstellung und das, was moderne Browser annehmen, wenn das Attribut fehlt, aber eine Browser-Voreinstellung anzunehmen ist nicht dasselbe wie sie hinzuschreiben, und ältere Clients nehmen sie nicht an. Strict ist sicherer und wird Leute ausloggen, die über einen externen Link ankommen. None ist nur bei echter Cross-Site-Nutzung legitim und verlangt Secure daneben.

Welche Cookies wir bewerten und welche wir durchlassen

Nicht jedes Cookie braucht jedes Flag. Ein Analytics- oder Präferenz-Cookie ohne Identität lohnt kein Schloss, und es zu melden würde dich darauf trainieren, den Report zu ignorieren. Wir gewichten die, deren Namen nach Session und Authentifizierung aussehen, denn dort hat ein fehlendes Flag echte Folgen.

So behebst du es

Diese Flags werden dort gesetzt, wo das Cookie entsteht, nicht in einer globalen Konfigurationsdatei, und genau deshalb werden sie übersehen: es gibt keine einzelne Stelle, an der man sie behebt, und jede Bibliothek schreibt sie anders. Die Beispiele unten setzen alle drei auf einmal.

Der Header selbst

Set-Cookie: session=abc123; Path=/; Max-Age=604800;
  Secure;
  HttpOnly;
  SameSite=Lax

# Secure   -> https only
# HttpOnly -> invisible to document.cookie
# SameSite -> not sent on cross-site requests

# Note: SameSite=None REQUIRES Secure, and browsers drop the cookie
# entirely if you set None without it. That silent drop is a common
# cause of "my login works locally and not in production".

Next.js

import { cookies } from "next/headers";

(await cookies()).set("session", token, {
  httpOnly: true,
  secure: process.env.NODE_ENV === "production",
  sameSite: "lax",
  path: "/",
  maxAge: 60 * 60 * 24 * 7,
});

Express

// Behind a proxy or load balancer, "secure" cookies are dropped
// unless Express is told to trust the forwarded protocol. Missing
// this is why the flag silently does nothing in production.
app.set("trust proxy", 1);

res.cookie("session", token, {
  httpOnly: true,
  secure: true,
  sameSite: "lax",
  maxAge: 1000 * 60 * 60 * 24 * 7,
});

Hono, Fastify und Verwandte

// Hono
import { setCookie } from "hono/cookie";

setCookie(c, "session", token, {
  httpOnly: true,
  secure: true,
  sameSite: "Lax",
  path: "/",
  maxAge: 60 * 60 * 24 * 7,
});

// Fastify (@fastify/cookie)
reply.setCookie("session", token, {
  httpOnly: true,
  secure: true,
  sameSite: "lax",
  path: "/",
});

Was dieses Tool nicht sehen kann

Wir sehen die Cookies, die deine Seite auf der einen Seite setzt, die wir angefordert haben, vor jedem Login. Die Cookies, auf die es am meisten ankommt, werden meist in dem Moment gesetzt, in dem sich jemand anmeldet, in einer Antwort, die wir nie bekommen. Ein sauberes Ergebnis hier ist also kein Beleg dafür, dass dein Session-Cookie korrekt ist. Sieh dir in den DevTools auch die Antwort auf deine eigene Login-Anfrage an. Und Flags sind nur die Transporthälfte des Problems: sie sagen nichts darüber, wie lange die Session gilt, ob sie beim Abmelden ungültig wird, oder ob sich das Token darin fälschen lässt.

Auch den Code scannenZum Einstieg kostenlos. Repository verbinden, der erste Scan läuft in rund zwei Minuten.