EMZETT.Cookies
Kurz: Kleine Datenstücke, die ein Webserver im Browser eines Nutzers speichert und bei jedem weiteren Aufruf derselben Seite automatisch mitgeschickt bekommt — Grundlage für Sessions und Login-Zustände im zustandslosen HTTP.
Genauer: Da HTTP von Natur aus zustandslos ist (jede Anfrage ist unabhängig, der Server “erinnert” sich nicht), braucht es einen Mechanismus, um einen Nutzer über mehrere Anfragen hinweg wiederzuerkennen — dafür wurden Cookies erfunden. Wichtige Sicherheitsattribute: HttpOnly (nicht per JavaScript auslesbar, schützt vor XSS-Diebstahl), Secure (nur über HTTPS gesendet) und SameSite (schränkt ein, bei welchen websiteübergreifenden Anfragen der Cookie mitgeschickt wird, schützt vor CSRF).
Im Detail
Ein Server setzt einen Cookie über den Set-Cookie-Response-Header, der Browser schickt ihn danach automatisch bei jeder weiteren Anfrage an dieselbe Domain mit:
Set-Cookie: session_id=a3f9c2...; HttpOnly; Secure; SameSite=Lax; Max-Age=3600; Path=/
Jedes Attribut hat eine konkrete Sicherheitsfunktion:
HttpOnly— der Cookie ist überdocument.cookie(JavaScript) nicht auslesbar. Verhindert, dass ein per Cross-Site-Scripting (XSS) eingeschleustes Skript den Session-Cookie stiehlt und an einen Angreifer sendet.Secure— der Browser sendet den Cookie ausschließlich über eine verschlüsselte HTTPS-Verbindung, nie über unverschlüsseltes HTTP.SameSite=Strict/Lax/None— steuert, ob der Cookie bei Anfragen mitgeschickt wird, die von einer ANDEREN Website ausgelöst wurden.Strictblockt das komplett,Laxerlaubt es nur bei einfachen Navigationen (z. B. Klick auf einen Link),Noneerlaubt es uneingeschränkt (erfordert dann zwingendSecure). Schützt vor Cross-Site-Request-Forgery (CSRF), bei der eine bösartige Website versucht, im Namen des eingeloggten Nutzers Anfragen an eine andere Seite zu senden.
Man unterscheidet außerdem Session-Cookies (ohne Max-Age/Expires, verschwinden beim Schließen des Browsers) von persistenten Cookies (mit fester Ablaufzeit, überleben Neustarts). Drittanbieter-Cookies (gesetzt von einer anderen Domain als der besuchten, z. B. für Tracking über mehrere Websites hinweg) werden von modernen Browsern zunehmend standardmäßig blockiert.
First-Party vs. Third-Party Cookies
Der Unterschied ist entscheidend für Datenschutz und Tracking: Ein First-Party-Cookie wird von der Domain gesetzt, die der Nutzer tatsächlich besucht (z. B. shop.example.com setzt einen Warenkorb-Cookie für sich selbst) — das ist technisch notwendig und unproblematisch. Ein Third-Party-Cookie wird dagegen von einer ANDEREN Domain gesetzt, die als eingebettete Ressource auf der besuchten Seite lädt (z. B. ein Werbenetzwerk-Skript) — dieser Cookie kann dieselbe Werbefirma auf tausenden verschiedenen Websites wiedererkennen und daraus ein umfassendes Nutzerprofil erstellen. Chrome, Safari und Firefox haben Third-Party-Cookies in den letzten Jahren zunehmend eingeschränkt oder komplett blockiert, was die Werbebranche zu alternativen (teils datenschutzfreundlicheren) Tracking-Methoden zwingt.
Cookie-Größenlimits und praktische Grenzen
Browser begrenzen die Größe und Anzahl von Cookies pro Domain (üblicherweise 4 KB pro Cookie, ca. 50-180 Cookies pro Domain je nach Browser) — deshalb speichern moderne Anwendungen im Cookie meist nur eine kurze, zufällige Session-ID, während die eigentlichen Nutzerdaten serverseitig (Datenbank, Redis) unter dieser ID abgelegt werden, statt sie direkt im Cookie zu transportieren.
Rechtlicher Rahmen in der EU
In der EU regelt die ePrivacy-Richtlinie (umgangssprachlich “Cookie-Richtlinie”) zusätzlich zur DSGVO, dass für nicht technisch notwendige Cookies (also praktisch alles außer Session-/Sicherheits-Cookies) eine aktive Einwilligung des Nutzers eingeholt werden muss, bevor sie gesetzt werden dürfen — die allgegenwärtigen Cookie-Banner auf europäischen Websites sind die direkte Folge dieser Regelung. Rein funktionale Cookies (z. B. ein Warenkorb-Cookie oder ein Session-Cookie für den Login) benötigen dagegen keine Einwilligung, weil sie für die angeforderte Funktion technisch zwingend erforderlich sind.