Begriff

Cookie (HTTP Cookie)

Web Development S1

2 Quellen 0 Lernpfade 1 Backlink enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

HTTP hat Alzheimer. Wenn du Seite A lädst und dann Seite B, weiß der Server nicht mehr, wer du bist. Lösung: Der Server gibt dir beim ersten Besuch einen kleinen Zettel (Cookie) mit. "Du bist User 123." Dein Browser speichert den Zettel. Bei jedem weiteren Klick auf dieser Seite zeigt dein Browser den Zettel automatisch vor. Server: "Ah, User 123 ist wieder da." Ohne Cookies gäbe es keinen Login und keinen Warenkorb.

Merksatz: Eine kleine Textdatei, die vom Webserver an den Browser gesendet und dort gespeichert wird, um Benutzer bei nachfolgenden Anfragen wiederzuerkennen (Zustandserhaltung).

In den DevTools (F12) -> Application -> Cookies. Du siehst Name (session_id) und Wert (xyz...). In PHP: setcookie("user", "Max", time()+3600); Achtung: Cookies sind auf 4KB begrenzt. Speichere dort keine großen Daten!

1. Security Flags (Lebenswichtig!)

Wenn du ein Cookie setzt, musst du Flags setzen:

HttpOnly: JavaScript (document.cookie) darf das Cookie nicht lesen. Schützt vor XSS (Hacker kann Session-ID nicht klauen).
Secure: Cookie wird nur über HTTPS gesendet. Schützt vor Man-in-the-Middle.
SameSite: Strict oder Lax. Verhindert CSRF (siehe CSRF Artikel).

2. Third-Party Cookies

Cookies von facebook.com, während du auf spiegel.de bist. Dienen nur dem Tracking (Werbung). Browser (Safari, Firefox, bald Chrome) blockieren diese Cookies mittlerweile standardmäßig ("Cookie Apocalypse"). AdTech-Firmen suchen verzweifelt nach Alternativen (Fingerprinting).

3. DSGVO / GDPR

"Diese Seite nutzt Cookies." - Der nervige Banner. Technisch nötige Cookies (Warenkorb/Login) brauchen keine Zustimmung. Tracking/Marketing-Cookies brauchen Zustimmung (Opt-In). Fast alle Banner sind eigentlich illegal gestaltet ("Dark Patterns").

1. Der Set-Cookie Header (Syntax & Flags)

Technisch existiert das Cookie als reiner Text im HTTP Response Header, wenn ein Server eine Antwort sendet: Set-Cookie: session_id=abc1234; Domain=.firma.com; Path=/; Expires=Wed, 21 Oct 2025 07:28:00 GMT; Secure; HttpOnly; SameSite=Strict

Domain & Path: Restriktiert strikt, ob das Cookie nur auf support.firma.com oder quer über alle Subdomains gültig ist.
HttpOnly: Ein kritisches Security-Muss für Sessions. Setzt der Browser dieses Flag für den Text-String abc1234 im internen Cookie-Jar fest, wird es unsichtbar für die document.cookie JavaScript-API. Bei einem XSS-Angriff (Cross-Site Scripting) kann ein eingeschleustes Hacker-Skript die Session des Opfers nicht mehr auslesen.
Secure: Erzwingt die strikte Auslieferung nur über den HTTPS (Hypertext Transfer Protocol Secure) Tunnel.
SameSite=Lax/Strict: Definiert, ob der Browser das Cookie verschickt, wenn der User über einen fremden Link (z.B. aus einer E-Mail oder einem fremden Forum) auf die Seite gelangt (Verhinderung von klassischem CSRF).

2. Cookie Manipulation & Cryptographic Signing

Cookies liegen auf der Festplatte des Users. Ein findiger User drückt F12 und ändert den Cookie-String role=user auf role=admin ab. Liest der Node.js Server diesen String naiv aus, wird der User zum Gott. Alle Backend-Frameworks (Express, Laravel, Spring) begegnen diesem Problem durch Signed Cookies. Der Server hascht die Payload mit seinem supergeheimen Server-Key (HMAC SHA-256) als Signatur. Der Browser erhält: role=user.e9b8b.... Ändert der User "user" in "admin", wird der Hash e9b8b... bei der Validierung auf dem Server ungültig, das Framework erkennt die Fälschung (Tampering) sofort und verweigert die Annahme (403 Unauthorized).

3. ITP (Intelligent Tracking Prevention) & Cookieless Future

Tech-Giganten (wie Apple mit ITP in Safari und bald Chrome) schotten Cookies immer weiter durch Restriktionen ab. Third-Party-Cookies (Cookies der Domain ad.com, während man auf blog.com surft) werden verworfen. Selbst First-Party-Cookies, die per JavaScript (statt sauber über HTTP Headers) generiert werden, vernichtet Safari künstlich nach maximal 7 Tagen. Dies bedroht die Lebenszyklen von Affiliate-Tracking-Links immens. Marketing-Industrien flüchten deshalb in weitaus übergriffigere (ohne Consent fast unsichtbare) Lösungen wie CSS Font-Fingerprinting oder TLS-Handshake-Sniffing (Cname Cloaking / Server Side Tagging), um User-Uniqueness zu erzwingen.

Quick-Check

Session vs. Persistent?
Session-Cookie: Hat kein Ablaufdatum. Wird gelöscht, wenn Browser geschlossen wird. Persistent-Cookie: Hat Expires=2025. Bleibt auch nach Neustart da ("Angemeldet bleiben").
Kann ich Cookies löschen?
Ja, der User hat die volle Kontrolle. Ein Entwickler darf sich nie darauf verlassen, dass ein Cookie für immer da bleibt.
Signed Cookies?
Um Manipulation zu verhindern (user=admin fälschen), signiert das Framework das Cookie (user=admin.HashedSignature). Wenn der User es ändert, stimmt die Signatur nicht mehr -> Server verwirft es.