Cookies sind in PHP schnell gesetzt, doch ein blanker setcookie-Aufruf reicht heute nicht mehr aus. Moderne Browser erwarten klare Sicherheitsangaben, und genau dort kommen die Flags SameSite, HttpOnly und Secure ins Spiel. Dieses Tutorial zeigt, wie du sie richtig kombinierst und worauf es bei Session-Cookies besonders ankommt.
Warum drei Flags für einen Cookie?
Wer in einer modernen PHP-Anwendung Cookies setzt, kommt am Trio PHP Cookie SameSite, HttpOnly und Secure nicht mehr vorbei. Browser sind in den letzten Jahren sehr viel strenger geworden: Cookies ohne SameSite werden mit Warnungen versehen oder ganz blockiert, Cookies ohne Secure über HTTPS abgelehnt, Cookies ohne HttpOnly sind ein klassisches XSS-Ziel.
Bevor die einzelnen Flags und das Options-Array von setcookie() im Detail folgen, hier ein kurzer Überblick über das Risiko, das jedes der drei Flags abdeckt.
Die drei Flags decken jeweils ein eigenes Risiko ab. SameSite begrenzt, in welchen Kontexten der Cookie überhaupt mitgeschickt wird, und schützt damit vor CSRF. HttpOnly entzieht JavaScript den Zugriff und macht Cookie-Diebstahl per XSS deutlich schwerer. Secure stellt sicher, dass der Cookie nur über verschlüsselte Verbindungen reist. In Summe ergeben sie eine Mindest-Konfiguration für jeden Auth- oder Session-Cookie.
setcookie mit Options-Array seit PHP 7.3
Früher musste man setcookie() mit positionalen Parametern aufrufen. Diese alte Form unterstützt SameSite nicht. Seit PHP 7.3 gibt es eine Variante mit Options-Array, die heute Standard sein sollte.
<?php
setcookie('sitzung', $token, [
'expires' => time() + 3600,
'path' => '/',
'secure' => true,
'httponly' => true,
'samesite' => 'Lax',
]);
Diese Form ist nicht nur übersichtlicher, sondern erlaubt es überhaupt erst, das samesite-Feld als eigenes Feature zu konfigurieren. setcookie() akzeptiert das Options-Array seit PHP 7.3 und macht damit das SameSite-Feature direkt zugänglich. Wer die Basics von setcookie erst noch nachholen möchte, findet sie im Tutorial setcookie() von A bis Z. Im weiteren Verlauf konzentriert sich dieses Tutorial auf die drei Sicherheits-Flags.
PHP Cookie SameSite Strict, Lax und None im Vergleich
Im Zentrum stehen drei Werte mit klar unterschiedlicher Wirkung. Die folgende Schnellreferenz hilft bei der Auswahl.
<?php
/*
* Strict: Cookie nur bei same-site Requests, blockt jeden cross-site Request
* Lax : Cookie bei Top-Level-Navigation (Linkklick), blockt iframe + XHR
* None : Cookie wird in jedem Kontext gesendet, ABER nur mit Secure-Flag erlaubt
*/
Strict ist der härteste Wert. Klickt ein Nutzer von einer fremden Seite einen Link in deine Anwendung, wird der Cookie nicht mitgesendet, sodass er beim Ankommen frisch eingeloggt sein muss. Das ist die sicherste Wahl, führt aber bei vielen Webseiten zu unangenehmen Login-Dialogen, wenn jemand einen Bookmark oder eine externe Suche-Trefferliste verwendet.
Lax ist der gängige Mittelweg. Der Cookie wird bei normaler Top-Level-Navigation mitgesendet, also wenn der Nutzer einen Link aktiv anklickt. Bei Hintergrund-Requests aus einem fremden iframe, einem <img>-Tag oder einem cross-site fetch() bleibt der Cookie außen vor. Das ist genau das CSRF-Schutzziel, ohne den Login-Komfort zu zerstören.
None ist der freizügigste Wert und ausdrücklich dafür gedacht, einen Cookie auch in fremden Kontexten mitzuschicken. Klassischer Anwendungsfall sind eingebettete Widgets oder iframe-Embeds einer SaaS. Der Browser akzeptiert SameSite=None allerdings nur, wenn gleichzeitig Secure gesetzt ist.
HttpOnly als Begleitflag gegen XSS-Cookie-Diebstahl
Der HttpOnly-Flag entzieht dem clientseitigen JavaScript den Zugriff auf den Cookie und gehört in jede saubere Cookie-Konfiguration. Liest ein Angreifer über eine XSS-Lücke document.cookie aus, fehlen alle Cookies mit dem Flag im Ergebnis. Damit verliert ein erfolgreicher XSS-Angriff einen Großteil seiner Wirkung gegenüber Auth-Cookies.
<?php
setcookie('auth_token', $token, [
'expires' => time() + 3600,
'path' => '/',
'secure' => true,
'httponly' => true, /* JavaScript darf den Cookie nicht lesen */
'samesite' => 'Lax',
]);
HttpOnly ist kein Allheilmittel, denn ein Angreifer mit XSS-Zugriff kann immer noch Aktionen im Namen des Nutzers ausführen. Aber der Cookie-Wert verlässt die Browser-Sandbox nicht mehr und kann nicht in eine spätere Session importiert werden. Mehr über die Rolle von HttpOnly im sicheren Login zeigt das Tutorial zu session_regenerate_id und Session-Sicherheit.
Secure als Pflichtbegleiter für HTTPS-Cookies
Der Secure-Flag sorgt dafür, dass der Browser den Cookie nur über HTTPS sendet. Ein Mitleser im WLAN oder im Mobilnetz sieht die Header dann nicht mehr im Klartext. Wer Secure nicht setzt, riskiert dagegen, dass beim ersten Aufruf einer http-URL die Session-ID abfangbar wird.
<?php
setcookie('analytics', $value, [
'expires' => time() + 86400,
'path' => '/',
'secure' => true,
'httponly' => false,
'samesite' => 'Lax',
]);
/* Secure setzt ueberall HTTPS voraus, auch lokal beim Testen */
Beim lokalen Entwickeln auf http://localhost werden Secure-Cookies vom Browser ignoriert. Das führt manchmal zu Verwirrung, wenn Cookies "wie weg" sind. Lösung: lokal mit selbstsigniertem HTTPS arbeiten oder Secure nur in der Produktionskonfiguration aktivieren.
Session-Cookies mit PHP Cookie SameSite konfigurieren
Sessions schicken einen eigenen Cookie mit der Session-ID. Dieser Cookie braucht dieselben Flags wie alle anderen Auth-Cookies und gehört damit ebenfalls in eine durchdachte SameSite-Konfiguration. PHP bietet dafür zwei Wege: session_set_cookie_params() direkt vor session_start() und die statische Konfiguration in der php.ini.
<?php
session_set_cookie_params([
'lifetime' => 0,
'path' => '/',
'secure' => true,
'httponly' => true,
'samesite' => 'Strict',
]);
session_start();
Wer auf Anwendungsebene flexibel bleiben will, ergänzt ini_set()-Aufrufe. Auf Hosting-Ebene gehören die folgenden Direktiven in die php.ini oder eine .user.ini.
<?php
/* Direktiven fuer php.ini bzw. .user.ini:
*
* session.cookie_secure = 1
* session.cookie_httponly = 1
* session.cookie_samesite = "Lax"
*/
ini_set('session.cookie_secure', '1');
ini_set('session.cookie_httponly', '1');
ini_set('session.cookie_samesite', 'Lax');
session_start();
So bekommt jeder Session-Start automatisch die richtigen Flags, auch wenn ein Skript das einmal vergessen sollte.
PHP Cookie SameSite im Spezialfall Cross-Site und Subdomains
Subdomains derselben Hauptdomain gelten beim PHP Cookie SameSite als same-site. Ein Cookie von app.example.com wird auch an api.example.com gesendet, sofern das Domain-Attribut entsprechend gesetzt ist. Cross-Site dagegen bedeutet eine vollständig andere Registrable-Domain, etwa example.com und widget-host.com.
<?php
/* iframe-Embed auf einer fremden Domain */
setcookie('embed_token', $token, [
'expires' => time() + 3600,
'path' => '/',
'domain' => '.example.com',
'secure' => true,
'httponly' => true,
'samesite' => 'None',
]);
SameSite=None ist hier zwingend, sonst würde der Cookie nicht ankommen. Gleichzeitig ist Secure Pflicht, weil Browser sonst die Kombination ablehnen. Wer ein Embed-Widget oder eine SSO-Bridge baut, kommt an dieser SameSite-Konfiguration nicht vorbei. Für Widgets, die nur intern auf Subdomains deployt sind, reicht dagegen Lax mit explizitem domain-Attribut.
Browser-Defaults: Was passiert ohne SameSite-Angabe?
Eine wichtige Frage in der Praxis: Wie verhalten sich Browser, wenn SameSite überhaupt nicht gesetzt ist? Bis Anfang 2020 galt der Default None, das heißt Cookies wurden in jedem Kontext mitgesendet. Das änderte Google mit Chrome 80 im Februar 2020 schrittweise auf Lax als impliziten Default, andere Chromium-basierte Browser (Edge, Opera, Brave) zogen sofort nach. Firefox aktivierte denselben Default 2021, Safari hatte schon vorher eine vergleichbare Politik.
<?php
/* Ohne SameSite: Browser interpretiert als Lax */
setcookie('legacy', $value, time() + 3600, '/');
/* Mit explizitem Lax: identisches Verhalten, aber kein Browser-Warnhinweis */
setcookie('modern', $value, [
'expires' => time() + 3600,
'path' => '/',
'samesite' => 'Lax',
]);
Das hat zwei praktische Konsequenzen. Erstens: Cookies, die in Cross-Site-Kontexten ankommen sollen (Embed-Widgets, SSO-Bridges, iframe-Logins), müssen explizit SameSite=None; Secure setzen, sonst verweigern moderne Browser die Aussendung. Zweitens: Selbst wer nichts angibt, lebt nicht mehr im "alles erlaubt"-Zustand, sondern bekommt das Lax-Verhalten unter der Haube. Wer auf Legacy-Code stösst, in dem SameSite fehlt, sollte den Wert nachträglich explizit setzen, um sich nicht auf Browser-Defaults zu verlassen, die kommendes Jahr wieder anders aussehen könnten.
Für PHP-Versionen vor 7.3, in denen das Options-Array von setcookie() noch nicht verfügbar war, gibt es einen Legacy-Trick über das path-Argument: setcookie('name', $value, $expires, '/; samesite=Lax'). Das hängt das Attribut händisch an den Set-Cookie-Header. Für moderne Setups ab PHP 7.3 ist diese Methode nicht mehr nötig und sollte beim Refactoring durch das saubere Options-Array ersetzt werden.
Stolperfallen rund um PHP Cookie SameSite
Drei Fehler tauchen rund um PHP Cookie SameSite besonders häufig auf. Erstens: alter setcookie-Aufruf ohne Options-Array, dadurch fehlt SameSite still im Header. Zweitens: SameSite=None ohne Secure, was vom Browser komplett verworfen wird. Drittens: Secure-Cookie während lokaler HTTP-Entwicklung, der dann scheinbar verschwindet.
Auch wichtig: SameSite ersetzt kein CSRF-Token. Es senkt das Risiko erheblich, aber gegen einen Angriff aus derselben Site (etwa von einer User-generated-Content-Seite) hilft es nicht. Sensitive POST-Aktionen sollten weiterhin ein Token im Formular tragen.
flowchart TD
A[Browser auf evil.com] --> B[Request an bank.com]
B --> C{SameSite gesetzt?}
C -->|Strict| D[Cookie NICHT mitgesendet]
C -->|Lax + Top-Navigation| E[Cookie mitgesendet]
C -->|Lax + iframe / XHR| F[Cookie NICHT mitgesendet]
C -->|None + Secure| G[Cookie mitgesendet]
Fazit zu PHP Cookie SameSite
PHP Cookie SameSite, HttpOnly und Secure sind drei kleine Flags mit großer Wirkung. Wer setcookie konsequent über das Options-Array aufruft und alle drei Werte setzt, hat eine moderne Cookie-Konfiguration, die mit aktuellen Browsern reibungslos zusammenarbeitet und gegen die häufigsten Cookie-Risiken schützt. Für Session-Cookies sorgen session_set_cookie_params() und die passenden session.cookie_*-Direktiven dafür, dass auch der wichtigste Auth-Cookie korrekt geschützt ist. PHP Cookie SameSite ist dabei der entscheidende Schritt, ohne den jeder Session-Cookie heute als unvollständig gilt.
