Zustandslosigkeit und Cookies

In dieser interaktiven Lerneinheit verstehst du das Konzept der HTTP-Zustandslosigkeit und lernst, wie Cookies diese Einschränkung überwinden. Du erfährst, wie Webanwendungen Nutzerdaten zwischen Anfragen speichern und Sitzungen verwalten können. Diese Grundlagen sind essentiell für die Entwicklung moderner Webanwendungen, bei denen Nutzer eingeloggt bleiben oder Warenkörbe gespeichert werden müssen.

Lernziele

Stell dir vor, du loggst dich auf einer Website ein, klickst auf einen Link – und bist plötzlich wieder ausgeloggt. Oder dein Warenkorb ist leer, obwohl du gerade noch Produkte hinzugefügt hast. Frustrierend, oder? Solche Probleme treten auf, wenn Webanwendungen nicht korrekt mit Zustand umgehen. Doch warum ist das überhaupt eine Herausforderung?

Der Grund liegt im Protokoll, auf dem das Web basiert: HTTP ist von Natur aus zustandslos. Das heißt, der Server behandelt jede Anfrage so, als ob sie die erste wäre. Damit trotzdem Funktionen wie Logins, Warenkörbe oder Spracheinstellungen funktionieren, braucht es Zusatzmechanismen.

Lernziele

Nach dieser Lerneinheit kannst du:

  • erklären, was Zustandslosigkeit im Kontext des HTTP-Protokolls bedeutet und welche Vor- und Nachteile damit verbunden sind,
  • beschreiben, wie Webanwendungen mittels Cookies, Sessions und weiteren Techniken Zustand über HTTP-Anfragen hinweg speichern,
  • die Unterschiede zwischen Session-Cookies und permanenten Cookies benennen und ihre jeweiligen Einsatzszenarien erklären,
  • zentrale Cookie-Attribute wie Secure, HttpOnly, SameSite, Max-Age, Expires, Domain und Path verstehen und ihre Bedeutung für Sicherheit und Gültigkeit eines Cookies beurteilen.

Überleitung

Um zu verstehen, warum Webanwendungen auf Cookies, Sessions und andere Mittel zur Zustandshaltung angewiesen sind, musst du zuerst wissen, was es bedeutet, dass HTTP zustandslos ist.

Was bedeutet Zustandslosigkeit bei HTTP?

HTTP ist ein zustandsloses Protokoll. Das heißt: Jeder Request (also jede Anfrage) wird unabhängig behandelt. Der Server speichert keine Informationen über frühere Interaktionen mit dem Client. Selbst wenn du direkt hintereinander zwei Seiten aufrufst, “weiß” der Server beim zweiten Aufruf nicht, dass du gerade schon einmal mit ihm kommuniziert hast.

Diese Eigenschaft hat sowohl Vorteile als auch Nachteile:

Vorteile der Zustandslosigkeit

  • Einfachheit: Der Server muss keine Benutzerdaten zwischen den Anfragen speichern. Das macht die Kommunikation leichter nachvollziehbar und reduziert Komplexität.
  • Skalierbarkeit: Da keine zustandsbezogenen Daten gespeichert werden, lassen sich HTTP-Dienste einfacher horizontal skalieren. Neue Server können hinzugefügt werden, ohne dass Sitzungsdaten synchronisiert werden müssten.

Nachteile der Zustandslosigkeit

  • Erhöhter Aufwand: Informationen wie Login-Status, Spracheinstellungen oder der Inhalt eines Warenkorbs müssen bei jeder Anfrage neu übertragen werden.
  • Begrenzte Funktionalität: Viele Webanwendungen benötigen dennoch eine persistente Speicherung von Informationen über den Nutzerzustand.

Wie lösen Webanwendungen dieses Problem?

Obwohl HTTP selbst keine Zustände speichert, müssen Webanwendungen eine kontinuierliche Nutzererfahrung ermöglichen. Dazu greifen sie auf verschiedene Mechanismen zur Zustandshaltung zurück:

Cookies

Ein Cookie ist eine kleine Textdatei, die ein Server an den Browser sendet. Dieser speichert sie lokal. Bei späteren Anfragen an dieselbe Domain schickt der Browser das Cookie automatisch wieder mit.

Wofür werden Cookies genutzt?

  • Session-Management: z. B. Login-Sessions
  • Personalisierung: z. B. Sprache oder Darstellung
  • Tracking: z. B. für Webanalyse oder Werbung

Beispiel: Setzen und Senden von Cookies

Set-Cookie: sessionid=abc123; Path=/; Expires=Wed, 09 Jun 2027 10:18:14 GMT; HttpOnly; SameSite=Strict; Secure
Cookie: sessionid=abc123
  • Secure: Wird nur über HTTPS übertragen
  • HttpOnly: Nicht per JavaScript zugreifbar (Schutz vor Cross-Site Scripting)
  • SameSite: Schützt vor Cross-Site Request Forgery (CSRF)

Sessions (Sitzungen)

Sitzungen speichern Nutzerdaten serverseitig. Der Client erhält nur eine ID, meist als Cookie.

Ablauf eines Session-Managements:

  1. Du rufst eine Seite auf.
  2. Der Server erzeugt eine Session-ID und speichert deine Daten intern (z. B. Benutzername).
  3. Die Session-ID wird im Browser als Cookie gespeichert.
  4. Bei jeder weiteren Anfrage sendet dein Browser die Session-ID mit.
  5. Der Server erkennt dich wieder und stellt deine Daten bereit.

Vorteile von Sessions:

  • Nutzerdaten liegen nicht auf dem Client (bessere Sicherheit)
  • Auch komplexe Objekte können gespeichert werden

Weitere Techniken zur Zustandshaltung

Neben Cookies und Sessions gibt es noch andere Wege, um Nutzerzustand zu speichern:

  • URL-Rewriting: Die Session-ID wird an die URL angehängt, z. B. example.com/shop;jsessionid=xyz
  • Versteckte Formularfelder: Daten werden als unsichtbare Felder im Formular übermittelt
  • Web Storage (localStorage / sessionStorage): Der Browser speichert Daten lokal (v. a. für moderne Single Page Applications)
  • Tokens (z. B. JWT = JSON Web Token): Besonders im API-Kontext verbreitet, um Zustände clientseitig und gleichzeitig sicher zu halten
⏳ Lädt Dataview-Inhalt...

Warum sind Cookies für Webanwendungen so wichtig?

Cookies ermöglichen es Webanwendungen, über das eigentlich zustandslose HTTP-Protokoll hinweg Zustand zu speichern. Zwei Cookie-Arten spielen dabei eine zentrale Rolle: Session-Cookies und permanente Cookies.

Session-Cookies

Session-Cookies gelten nur für die Dauer einer Browser-Sitzung. Sie werden im Arbeitsspeicher des Browsers gespeichert und beim Schließen des Browsers automatisch gelöscht.

Typische Einsatzbereiche sind:

  • Temporäre Logins
  • Navigation durch geschützte Bereiche
  • Zwischenspeicherung von Formulardaten

Beispiel:

Set-Cookie: sessionid=123456789; Path=/; Secure; HttpOnly

Das Cookie wird nur über HTTPS übertragen (Secure) und kann nicht per JavaScript ausgelesen werden (HttpOnly).

Permanente Cookies

Permanente Cookies überdauern das Schließen des Browsers. Sie enthalten ein Ablaufdatum (Expires) oder eine Zeitangabe (Max-Age), nach der sie automatisch gelöscht werden.

Sie dienen z. B. zur:

  • Speicherung von Spracheinstellungen
  • Wiedererkennung bei zukünftigen Besuchen
  • “Angemeldet bleiben”-Funktion

Beispiel:

Set-Cookie: theme=dark; Max-Age=86400

Dieses Cookie speichert die gewählte Design-Einstellung für 24 Stunden.

Unterschiede im Überblick

MerkmalSession-CookiesPermanente Cookies
LebensdauerBis zum Schließen des BrowsersBis Ablauf von Max-Age oder Expires
SpeicherortRAM / ArbeitsspeicherFestplatte oder persistentem Speicher
VerwendungLogin-Sessions, NavigationEinstellungen, Wiedererkennung, “Angemeldet bleiben”

Secure

Dieses Attribut stellt sicher, dass Cookies nur über HTTPS übertragen werden. Es verhindert, dass sensible Daten unverschlüsselt durchs Netz gehen.

Set-Cookie: sessionId=abc123; Secure

HttpOnly

Ein Cookie mit dem Attribut HttpOnly ist nicht durch JavaScript zugreifbar. Das schützt vor Cross-Site Scripting (XSS).

Set-Cookie: userId=xyz789; HttpOnly

SameSite

SameSite erhöht den Schutz vor Cross-Site Request Forgery (CSRF). Es legt fest, wann Cookies bei Anfragen von anderen Seiten gesendet werden.

ModusVerhalten
StrictNur bei Anfragen derselben Seite
LaxAuch bei Link-Klicks und GET-Formularen
NoneImmer (nur mit Secure erlaubt)

Beispiel:

Set-Cookie: sessionId=abc123; SameSite=Strict

Max-Age und Expires

  • Max-Age definiert die Lebensdauer in Sekunden. Beispiel: Max-Age=3600 = 1 Stunde.
  • Expires setzt ein konkretes Ablaufdatum im GMT-Format.

Wenn beide vorhanden sind, hat Max-Age Vorrang.

Set-Cookie: sessionId=abc123; Max-Age=3600

Domain und Path

  • Domain legt fest, für welche (Sub-)Domains ein Cookie gültig ist. Beispiel: .example.com schließt sub.example.com mit ein.
  • Path beschränkt die Gültigkeit auf bestimmte Pfade innerhalb der Domain.
Set-Cookie: sessionId=abc123; Domain=example.com; Path=/admin
⏳ Lädt Dataview-Inhalt...

Zusammenfassung und Ausblick

Zusammenfassung:

HTTP ist ein zustandsloses Protokoll, was bedeutet, dass der Server keine Informationen über frühere Anfragen eines Clients speichert. Damit dennoch persistente Nutzererfahrungen wie Logins, Warenkörbe oder Spracheinstellungen möglich sind, greifen Webanwendungen auf Mechanismen zur Zustandshaltung zurück.

Zustandshaltung bei HTTP

  • Cookies sind kleine Textdateien, die Server an den Browser senden. Der Browser speichert sie und sendet sie bei weiteren Anfragen automatisch mit.
  • Sessions speichern Daten auf dem Server. Der Client erhält nur eine eindeutige Session-ID, meist per Cookie.
  • Weitere Techniken zur Zustandshaltung sind URL-Rewriting, versteckte Formularfelder, Web Storage und Tokens (z. B. JWT).

Aufbau und Attribute von Cookies

  • Session-Cookies bestehen nur für die Dauer einer Sitzung und werden beim Schließen des Browsers gelöscht.

  • Permanente Cookies bleiben über Sitzungen hinaus erhalten und besitzen ein Ablaufdatum oder eine Lebensdauer.

  • Wichtige Cookie-Attribute:

    • Secure: nur über HTTPS
    • HttpOnly: nicht durch JavaScript lesbar
    • SameSite: Schutz vor CSRF
    • Max-Age / Expires: Lebensdauer bzw. Ablaufzeitpunkt
    • Domain / Path: Geltungsbereich für das Cookie

Diese Mechanismen sind entscheidend, um Sicherheit, Benutzerfreundlichkeit und Funktionalität in modernen Webanwendungen zu gewährleisten.

Ausblick:

In der nächsten Lerneinheit beschäftigen wir uns mit Authentifizierungsmechanismen wie Basic Auth, Tokens und OAuth. Du wirst lernen, wie sich Nutzer sicher identifizieren und wie sich sensible Daten durch HTTPS und TLS-Verschlüsselung vor unbefugtem Zugriff schützen lassen.