🍪 PHP Cookie vs. 🔐 Session – Speicherung, Sicherheit und Unterschiede

Cookies und Sessions lösen ein ähnliches Problem: Sie speichern Informationen über einen Benutzer über mehrere Seitenaufrufe hinweg. Trotzdem funktionieren beide technisch sehr unterschiedlich.

Ein Cookie wird im Browser des Benutzers gespeichert. Eine Session speichert die eigentlichen Daten dagegen normalerweise auf dem Server. Der Browser erhält bei einer Session meist nur eine Session-ID.

🔎 Der wichtigste Unterschied

COOKIE

Browser
 └── language = de
 └── theme = dark
 └── consent = accepted

Die Daten befinden sich direkt beim Benutzer.

Bei einer Session sieht es eher so aus:

SESSION

Browser
 └── PHPSESSID = abc123...

          ↓

Server
 └── user_id = 42
 └── role = admin
 └── cart = [...]

Der Browser kennt hier normalerweise nur die Session-ID. Die eigentlichen Daten bleiben auf dem Server.

🍪 Was ist ein Cookie?

Ein Cookie ist eine kleine Information, die eine Website im Browser speichern kann.

In PHP lässt sich beispielsweise ein Sprach-Cookie setzen:

setcookie(
    'language',
    'de',
    time() + 86400 * 30,
    '/'
);

Ausgelesen wird der Wert über:

echo $_COOKIE['language'];

Cookies eignen sich gut für Informationen wie:

• Sprache
• Theme
• Cookie-Einwilligung
• Benutzerpräferenzen
• Tracking-Informationen
• „Angemeldet bleiben“-Funktionen mit sicherem Token

Der Benutzer kann Cookies jedoch normalerweise ansehen, löschen und teilweise verändern.

Deshalb sollten kritische Berechtigungen niemals allein auf einem normalen Cookie-Wert beruhen.

🔐 Was ist eine PHP Session?

Eine PHP Session speichert Benutzerinformationen serverseitig.

Sie wird gestartet mit:

session_start();

Danach können Daten gespeichert werden:

$_SESSION['user_id'] = 42;
$_SESSION['username'] = 'Max';
$_SESSION['role'] = 'admin';

PHP erzeugt dabei normalerweise einen Cookie namens:

PHPSESSID

Dieser enthält aber nicht direkt user_id, username oder role.

Er enthält lediglich eine Kennung, über die PHP die passende Session auf dem Server findet.

⚖️ Cookie und Session im direkten Vergleich

📦 Wie groß sind Cookies und Sessions?

Cookies sind relativ klein.

Als praktische Größenordnung gelten ungefähr:

4 KB pro Cookie

Das reicht problemlos für kleine Werte:

language=de

oder

theme=dark

Für große Datenmengen sind Cookies jedoch nicht gedacht.

Eine Session besitzt dagegen kein vergleichbares festes 4-KB-Limit.

Theoretisch könnte man beispielsweise große Arrays in einer Session speichern:

$_SESSION['products'] = $veryLargeArray;

Technisch möglich bedeutet aber nicht automatisch sinnvoll.

Große Session-Daten erhöhen:

• Speicherverbrauch
• Schreibzugriffe
• Ladezeiten
• Skalierungsaufwand

Besser ist häufig:

$_SESSION['user_id'] = 42;

und die eigentlichen Informationen anschließend aus Datenbank oder Cache zu laden.

⏱️ Wie lange bleiben Cookies erhalten?

Beim Erstellen eines Cookies kann eine Ablaufzeit angegeben werden.

Zum Beispiel:

setcookie(
    'language',
    'de',
    time() + 86400 * 30,
    '/'
);

Dieser Cookie soll ungefähr 30 Tage bestehen.

Ein Cookie kann aber auch als Session-Cookie angelegt werden. Dann wird er normalerweise nur für die aktuelle Browser-Sitzung verwendet.

⌛ Wie lange bleibt eine PHP Session?

Bei Sessions müssen zwei Dinge unterschieden werden:

Session-Cookie im Browser

und

Session-Daten auf dem Server

PHP verwendet häufig:

session.cookie_lifetime = 0

Damit ist die Session im Browser grundsätzlich an die Browsersitzung gebunden.

Für serverseitige Daten gibt es unter anderem:

session.gc_maxlifetime = 1440

1440 Sekunden entsprechen:

24 Minuten

Das bedeutet allerdings nicht automatisch, dass jede Session exakt nach 24 Minuten gelöscht wird.

Für Anwendungen mit Login sollte deshalb häufig zusätzlich eine eigene Inaktivitätsprüfung eingesetzt werden.

Beispiel:

$timeout = 1800;

if (
    isset($_SESSION['last_activity']) &&
    time() - $_SESSION['last_activity'] > $timeout
) {
    session_destroy();
}

$_SESSION['last_activity'] = time();

🗑️ Cookie löschen

Ein Cookie kann entfernt werden, indem man seine Ablaufzeit in die Vergangenheit setzt:

setcookie(
    'language',
    '',
    time() - 3600,
    '/'
);

🗑️ Session löschen

Eine Session wird beispielsweise beim Logout entfernt:

session_start();

$_SESSION = [];

session_destroy();

In einer vollständigen Logout-Implementierung sollte zusätzlich auch der Session-Cookie entfernt werden.

🔐 Was ist sicherer?

Eine klassische serverseitige Session ist für sensible Zustände normalerweise geeigneter als ein einfacher Cookie.

Warum?

Bei einem Cookie könnten beispielsweise Daten wie

role=admin

beim Benutzer gespeichert sein.

Darauf sollte die Anwendung niemals blind vertrauen.

Ein Benutzer könnte versuchen, diesen Wert zu verändern.

Bei einer Session befindet sich beispielsweise

$_SESSION['role'] = 'admin';

auf dem Server.

Der Benutzer bekommt lediglich seine Session-ID.

Allerdings bedeutet das nicht, dass Sessions automatisch sicher sind.

Die Session-ID selbst wird zu einem sehr wichtigen Sicherheitsmerkmal.

⚠️ Gefahren bei Sessions

Zu den wichtigsten Risiken gehören:

🕵️ Session Hijacking

Ein Angreifer bekommt eine gültige Session-ID.

Dann könnte er versuchen, die Sitzung des Benutzers zu übernehmen.

🎯 Session Fixation

Ein Angreifer versucht, einem Benutzer eine bereits bekannte Session-ID unterzuschieben.

Nach einem erfolgreichen Login sollte deshalb die Session-ID erneuert werden:

session_regenerate_id(true);

💉 XSS

Bei schlecht geschützten Cookies könnte JavaScript versuchen, Cookie-Daten auszulesen.

Dagegen hilft unter anderem:

HttpOnly

🌐 Unsichere Übertragung

Ohne HTTPS könnten Session-Informationen gefährdet sein.

Deshalb sollten sensible Anwendungen ausschließlich über HTTPS betrieben werden.

🛡️ Empfehlenswerte Cookie-Einstellungen

Für sicherheitsrelevante Cookies sind insbesondere diese Optionen interessant:

Secure
HttpOnly
SameSite

Beispielsweise:

session_set_cookie_params([
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Lax'
]);

session_start();

Secure

Cookie nur über HTTPS senden.

HttpOnly

JavaScript kann den Cookie nicht direkt über document.cookie auslesen.

SameSite

Hilft gegen bestimmte Cross-Site-Angriffe wie CSRF.

🛒 Beispiel: Warenkorb

Bei einem kleinen Warenkorb könnte man Produkt-IDs in einer Session speichern:

$_SESSION['cart'] = [
    12,
    27,
    34
];

Der Browser enthält nur:

PHPSESSID=...

Bei einem Cookie-basierten System könnte dagegen der Warenkorb oder eine Kennung direkt im Browser gespeichert werden.

Für komplexere Shops ist häufig eine Kombination sinnvoll:

Browser
   ↓
Session / Token
   ↓
Server
   ↓
Datenbank

🌍 Wann sollte man Cookies verwenden?

Cookies eignen sich besonders gut für langfristige, kleine Benutzereinstellungen.

Typische Beispiele:

Sprache
Dark Mode
Consent
Region
UI-Einstellungen

Beispiel:

setcookie('theme', 'dark', time() + 31536000);

Ein Theme muss meistens nicht extra serverseitig in einer Session gespeichert werden.

🔐 Wann sollte man Sessions verwenden?

Sessions sind besonders praktisch für:

Login
Benutzer-ID
Berechtigungen
Warenkorb
Flash Messages
mehrstufige Formulare
temporäre Zustände

Beispiel:

$_SESSION['user_id'] = 42;

Danach kann die Anwendung den vollständigen Benutzer aus der Datenbank laden.

🔄 Kann man Cookie und Session gleichzeitig verwenden?

Ja.

Genau das passiert bei klassischen PHP Sessions ohnehin.

Der Browser besitzt einen Cookie:

PHPSESSID=...

PHP verwendet diesen Cookie, um serverseitig die Session zu finden.

Man kann also vereinfacht sagen:

Eine klassische PHP Session verwendet häufig einen Cookie als Schlüssel für serverseitige Daten.

🚀 Welche Alternativen gibt es?

Für moderne Webanwendungen kommen auch andere Ansätze infrage.

Redis

Sessions werden zentral in Redis gespeichert.

Sehr nützlich bei mehreren Webservern.

Datenbank

Session-Daten liegen beispielsweise in MySQL.

Dadurch lassen sich Sessions zentral verwalten.

JWT

Ein signiertes Token kann bei APIs verwendet werden.

JWT ist jedoch nicht automatisch sicherer oder besser als Sessions.

localStorage

Clientseitige Speicherung im Browser.

Geeignet für nicht sensible Anwendungsdaten.

sessionStorage

Ähnlich wie localStorage, aber stärker an einen Browser-Tab beziehungsweise eine Sitzung gebunden.

🌐 Gibt es Cookies und Sessions auch außerhalb von PHP?

Ja.

Das Konzept ist nicht an PHP gebunden.

Node.js verwendet beispielsweise Session-Middleware wie:

express-session

Java kennt:

HttpSession

ASP.NET Core bietet:

HttpContext.Session

Python-Frameworks wie Flask oder Django besitzen ebenfalls eigene Session-Systeme.

Die technische Umsetzung kann unterschiedlich sein, das Grundproblem bleibt jedoch gleich:

HTTP ist zustandslos.

Die Anwendung muss erkennen,
welcher Request zu welchem Benutzer gehört.

✅ Cookie oder Session – was sollte man verwenden?

Es gibt kein pauschales „besser“.

Für kleine, langfristige Einstellungen sind Cookies sehr praktisch.

Für sensible serverseitige Zustände wie Login oder Benutzerrechte sind Sessions normalerweise besser geeignet.

In vielen Anwendungen werden beide Systeme kombiniert:

Cookie
    ↓
Session-ID
    ↓
Server
    ↓
Benutzerinformationen

Der wichtigste Grundsatz lautet:

Im Browser nur das speichern, was dort wirklich gespeichert werden muss. Sicherheitsrelevante Informationen sollten serverseitig kontrolliert werden.