Vollständiger Leitfaden zu Cookie-Sicherheitsflags｜Secure / HttpOnly / SameSite / __Host-

Cookie ist die am häufigsten verwendete Methode für Sitzungsverwaltung in Webanwendungen, aber ohne ordnungsgemäße Konfiguration können Angriffe wie <strong>Session Hijacking</strong>, <strong>CSRF</strong> (Cross-Site Request Forgery) und Token-Diebstahl via <strong>XSS</strong> entstehen. Dieser Artikel erklärt die Bedeutung der 4 wichtigsten Flags, die Cookies hinzugefügt werden sollten (<code>Secure</code> / <code>HttpOnly</code> / <code>SameSite</code> / <code>__Host-</code> Präfix), und fasst die Implementierungstücken zusammen.

Struktur des Set-Cookie-Headers

Wenn der Server ein Cookie im Browser setzt, gibt er einen Header wie folgt in der HTTP-Antwort zurück.

Set-Cookie: session_id=abc123; Path=/; Domain=example.com; Expires=Wed, 22 Apr 2026 10:00:00 GMT; Secure; HttpOnly; SameSite=Lax

Es gibt mehrere durch Semikolons getrennte Attribute, die hauptsächlich in 2 Typen unterteilt werden können.

1. <strong>Scope-Attribute</strong>: Path / Domain / Expires / Max-Age — bestimmt, wann und wohin das Cookie gesendet wird
2. <strong>Sicherheitsattribute</strong>: Secure / HttpOnly / SameSite — beschränkt Versand/Zugriff

Secure — Nur über HTTPS übertragen

Cookies mit dem Attribut <code>Secure</code> werden vom Browser <strong>nur bei HTTPS-Verbindungen</strong> an den Server gesendet. Ohne dieses Attribut kann das Cookie im Klartext übertragen werden, wenn das Opfer über <code>http://</code> auf die Website zugreift, was zu Man-in-the-Middle-Angriffen und zum Diebstahl der Session ID führen kann.

<strong>Goldene Regel:</strong> Immer bei authentifizierungsbezogenen Cookies hinzufügen. Bei der lokalen Entwicklung werden sichere Cookies auch ohne HTTPS auf localhost gesendet, aber es ist kein Problem, wenn die Produktion HTTPS voraussetzt.

HttpOnly — Nicht über JavaScript zugänglich

Wenn <code>HttpOnly</code> gesetzt ist, kann <code>document.cookie</code> den Cookie nicht mehr auslesen. Dies verhindert, dass JavaScript, das durch XSS-Angriffe eingefügt wird, den Cookie stehlen kann.

XSS ist nach wie vor eine mögliche Sicherheitslücke, daher sollten Sie dies für Session-Cookies als notwendig erachten. Wenn Sie den Cookie-Wert von der JavaScript-Seite aus lesen müssen (z. B. CSRF-Token), ist es bewährte Praxis, <strong>einen separaten schreibgeschützten Cookie zu erstellen</strong> oder den Wert <strong>über ein &lt;meta&gt;-Tag</strong> zu übergeben.

SameSite — Kontrollierte Übertragung bei Cross-Site-Anfragen

Das SameSite-Attribut ist das Kernstück des CSRF-Schutzes. Die Werte sind die folgenden 3:

Moderne Browser ab 2020 behandeln nicht spezifiziertes SameSite als <code>Lax</code>, daher erhalten Sie minimalen CSRF-Schutz auch ohne explizite Angabe, aber es ist besser, es explizit zu machen, um Ihre Absicht zu verdeutlichen.

Beim Verwenden von <code>SameSite=None</code> in SSO-Integration oder iframe-Einbettung muss <strong>immer auch Secure hinzugefügt werden</strong>, wie es moderne Browser erfordern. <code>SameSite=None</code>-Cookies ohne Secure werden vom Browser abgelehnt.

Präfix __Host- / __Secure-

Wenn der Cookie-Name mit <code>__Host-</code> beginnt, erzwingt der Browser die folgenden 3 Bedingungen.

• Flag <code>Secure</code> erforderlich
• Das Attribut <code>Domain</code> sollte nicht gesetzt werden (= nur der genaue Host, der die Anfrage gesendet hat)
• Muss <code>Path=/</code> sein

Diese bieten starke Garantien, dass 「sie nicht von anderen Subdomänen überschrieben werden können」 und 「Cookies nicht willkürlich durch Host-Header-Spoofing platziert werden können」. Am robustesten ist es, Session-Cookies ein Präfix wie <code>__Host-session</code> hinzuzufügen.

Das andere Präfix <code>__Secure-</code> erzwingt nur das erforderliche Secure-Flag (keine Domain- / Path-Einschränkungen).

4096-Byte-Limit

Der Wert von Cookie wird in RFC 6265 mit insgesamt <strong>4096 Bytes</strong> empfohlen. Wenn Sie große JSON oder Arrays in einem Cookie platzieren, können Sie diesen Grenzwert überschreiten und der Browser schneidet ihn stillschweigend ab. Der Standard ist, große Daten in server-seitigen Sitzungen zu speichern und nur die Sitzungs-ID im Cookie zu platzieren.

Implementierungsbeispiel: Authentifizierungs-Sitzungs-Cookie

Ein korrekt konfiguriertes Authentifizierungs-Cookie hat das folgende Format.

Set-Cookie: __Host-session=eyJ0eXAi...; Path=/; Max-Age=3600; Secure; HttpOnly; SameSite=Lax

• <code>__Host-</code>: verhindert Subdomain-Pollution und Host-Spoofing
• <code>Path=/</code>: auf der gesamten Website zugänglich
• <code>Max-Age=3600</code>: läuft nach 1 Stunde ab
• <code>Secure</code>: nur über HTTPS gesendet
• <code>HttpOnly</code>: nicht von JavaScript aus zugänglich
• <code>SameSite=Lax</code>: wird nicht bei Cross-Site POST gesendet (CSRF-Schutz)

Beispiel mit PHP (Laravel)

// config/session.php
return [
    'secure'     => true,      // Secure フラグ
    'http_only'  => true,      // HttpOnly フラグ
    'same_site'  => 'lax',    // SameSite=Lax
    'path'       => '/',
    'cookie'     => '__Host-session',
];

Beispiel mit Node.js (Express)

const session = require('express-session');

app.use(session({
  name: '__Host-session',
  secret: process.env.SESSION_SECRET,
  cookie: {
    secure:   true,
    httpOnly: true,
    sameSite: 'lax',
    path:     '/',
    maxAge:   3600 * 1000,
  },
}));

So überprüfen Sie die Cookie-Einstellungen einer bestehenden Website

Sie können sofort überprüfen, ob die Cookies Ihrer Website oder von Drittanbieter-Websites mit dem <a href="/ja/check/cookies/">Cookie-Inspektionstool von DevLab</a> korrekt eingestellt sind. Geben Sie einfach die URL ein, und das Tool analysiert alle zurückgegebenen Set-Cookie-Header und zeigt Diagnosen wie die folgenden an.

• Vorhandensein oder Fehlen von Secure / HttpOnly / SameSite für jeden Cookie
• Verstöße wie <code>SameSite=None</code> ohne Secure
• Konsistenz des Präfix __Host-
• Warnung bei Überschreitung von 4096 Bytes
• Gesamtzusammenfassung (Secure-Rate / HttpOnly-Rate / SameSite-Verteilung)

Zusammenfassung

Die Sicherheitsflags von Cookies sollten nicht 「einfach so gesetzt」 werden, sondern nach dem Verständnis des Angriffsszenarios und der entsprechenden Reaktion konfiguriert werden. Fügen Sie mindestens <strong>Secure + HttpOnly + SameSite + __Host--Präfix + kurzes Max-Age</strong> zu Authentication-Session-Cookies in der Produktion hinzu. Zur Überprüfung der Einstellungen bestehender Websites empfehlen wir die Verwendung des <a href="/ja/check/cookies/">Cookie-Inspektionstools</a>.