Was sind API-Cookies?

Was sind API-Cookies?

API-Cookies sind kleine Datenstuecke, die ein Server ueber HTTP-Antwort-Header beim Client setzt und die der Client bei spaeteren Anfragen an denselben Server zurueckschickt. Im API-Kontext tragen Cookies meist eine Session-Kennung oder ein Authentifizierungstoken, damit ein zustandsloser HTTP-Server bei jedem Aufruf erkennt, wer die Anfrage stellt, ohne jedes Mal nach Zugangsdaten zu fragen. Da HTTP selbst zustandslos ist, sind Cookies einer der aeltesten und am weitesten verbreiteten Mechanismen, um Zustand zwischen Client und API zu halten.

Cookies sind fuer alle wichtig, die APIs bauen oder testen. Ein Login-Endpunkt antwortet oft mit einem Set-Cookie-Header, und jeder geschuetzte Endpunkt danach erwartet, dass das Cookie zurueckkommt. Wenn Ihr API-Client, Monitor oder Lasttest-Skript Cookies nicht korrekt speichert und erneut sendet, schlagen authentifizierte Anfragen fehl, obwohl die API gesund ist.

Wie Cookies mit APIs funktionieren

Der Cookie-Austausch ist ein einfacher Hin- und Rueckweg ueber zwei HTTP-Header. Sendet ein Client eine Anfrage, kann der Server seiner Antwort einen Set-Cookie-Header anhaengen. Der Client speichert das Cookie und sendet es bei jeder folgenden Anfrage an eine passende Domain und einen passenden Pfad in einem einzigen Cookie-Header zurueck.

HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

Der Client wiederholt es bei nachfolgenden Aufrufen:

GET /api/v1/orders HTTP/1.1
Host: api.example.com
Cookie: sessionId=abc123

Der Server schlaegt abc123 in seinem Session-Speicher nach, findet den zugehoerigen Nutzer und autorisiert die Anfrage.

Session-Cookies und persistente Cookies

• Session-Cookies haben kein Expires- oder Max-Age-Attribut. Der Client behaelt sie nur bis zum Ende der Sitzung und verwirft sie dann. Ideal fuer kurzlebige Login-Sitzungen.
• Persistente Cookies tragen ein Expires-Datum oder ein Max-Age in Sekunden. Der Client speichert sie und sendet sie bis zum Ablauf zurueck. Sie treiben "Angemeldet bleiben" und langlebige Einstellungen an.

Bei APIs sind Authentifizierungs-Cookies meist sitzungsgebunden oder haben ein kurzes Max-Age, denn ein langlebiges Credential auf dem Client ist ein groesseres Risiko, falls es gestohlen wird.

Cookie-Attribute, die das Verhalten steuern

Attribut	Zweck
HttpOnly	Verhindert, dass JavaScript das Cookie ueber document.cookie liest, und begrenzt so den Schaden durch XSS.
Secure	Weist den Client an, das Cookie nur ueber HTTPS zu senden, also nie im Klartext.
SameSite	Steuert das Senden bei seitenuebergreifenden Anfragen. Werte sind Strict, Lax und None. Hauptschutz des Browsers gegen CSRF.
Domain	Legt fest, welche Hosts das Cookie erhalten, etwa auch Subdomains wie api.example.com.
Path	Beschraenkt das Cookie auf URLs unter einem Pfadpraefix wie /api.
Expires / Max-Age	Legt fest, wann das Cookie geloescht wird. Ohne Wert wird es ein Session-Cookie.

Das SameSite-Attribut verdient besondere Aufmerksamkeit. Strict haelt das Cookie bei jeder Anfrage von einer anderen Seite zurueck, Lax ist der moderne Standard und erlaubt es nur bei Navigationen der obersten Ebene, und None sendet es ueberall, verlangt aber Secure.

Cookie-Auth und Token-/Bearer-Auth

APIs authentifizieren meist auf zwei Arten. Cookie-basierte (Session-)Auth speichert eine Session-Kennung in einem Cookie, das der Browser automatisch anhaengt. Token-basierte Auth, etwa ein OAuth-2.0-Bearer-Token oder ein JSON Web Token (JWT), wird vom Client ausdruecklich im Authorization: Bearer <token>-Header gesendet.

Aspekt	Cookie-Auth	Token-/Bearer-Auth
Transport	Automatischer Cookie-Header	Manueller Authorization-Header
Zustand	Server haelt einen Session-Speicher	Oft zustandsloses, in sich geschlossenes Token
CSRF-Risiko	Anfaellig, braucht SameSite plus CSRF-Token	Nicht automatisch gesendet, geringeres Risiko
Passt zu	Browser-Apps auf einer Domain	Mobile Apps, Drittclients, Microservices

Keiner der Ansaetze ist grundsaetzlich besser. Cookies glaenzen bei First-Party-Web-Apps, weil HttpOnly das Credential vor Skripten schuetzt. Bearer-Token glaenzen bei mobilen Clients und Service-zu-Service-Aufrufen.

CSRF-Ueberlegungen

Der Komfort von Cookies, dass der Browser sie automatisch anhaengt, ist zugleich ihre Schwaeche. Bei einem Cross-Site Request Forgery (CSRF)-Angriff loest eine boeswillige Seite eine Anfrage an Ihre API aus, und der Browser fuegt das Session-Cookie des Opfers pflichtbewusst hinzu. Setzen Sie SameSite=Lax oder Strict und ergaenzen Sie ein CSRF-Token, das der Server ausstellt und der Client in einem Header echoen muss. Bearer-Token-APIs umgehen CSRF weitgehend, tragen dafuer aber die Last, das Token sicher gegen XSS zu speichern.

Cookies in REST und zustandslosem Design

REST als Architekturstil setzt auf Zustandslosigkeit: jede Anfrage soll alles Noetige mitbringen, ohne serverseitigen Kontext. Eine per Cookie referenzierte Server-Session dehnt dieses Prinzip, denn die Session lebt zwischen den Aufrufen auf dem Server. In der Praxis nutzen viele Teams Cookies fuer das Web-Frontend und zustandslose Bearer-Token fuer den programmatischen Zugriff.

Cookies in API-Clients und Testwerkzeugen

Jedes Werkzeug, das eine authentifizierte API aufruft, muss Cookies wie ein Browser verwalten: Set-Cookie aus Antworten erfassen, speichern und den passenden Cookie-Header bei spaeteren Anfragen erneut senden. Die meisten HTTP-Bibliotheken bieten dafuer eine Cookie-Ablage, und Werkzeuge wie curl haben die Flags --cookie-jar und --cookie.

Das ist direkt fuer Monitoring und Performance-Tests relevant. Ein API-Monitor, der einen eingeloggten Endpunkt prueft, muss zuerst den Login-Schritt ausfuehren, das zurueckgegebene Session-Cookie behalten und beim geschuetzten Aufruf mitsenden, sonst meldet er einen 401 und alarmiert Sie wegen einer Stoerung, die es nicht gibt. Dasselbe gilt fuer Lasttests: ein realistischer Lasttest loggt einen virtuellen Nutzer ein und gibt jedem simulierten Nutzer eine eigene Cookie-Ablage. Mit LoadFocus lassen sich solche mehrstufigen, cookie-bewussten Ablaeufe in JMeter oder k6 skripten, sodass authentifizierte Wege wie beim echten Nutzer geprueft werden.

Best Practices und Sicherheit

• Setzen Sie immer HttpOnly auf Authentifizierungs-Cookies.
• Setzen Sie Secure und liefern Sie die API ueber HTTPS aus.
• Nutzen Sie SameSite=Lax als Basis und Strict fuer sensible Aktionen.
• Halten Sie Sitzungen kurz und erneuern Sie Session-Kennungen bei Login und Logout.
• Speichern Sie nur eine undurchsichtige Kennung im Cookie, nie sensible Daten.
• Kombinieren Sie Cookie-Auth mit einem CSRF-Token bei jeder zustandsaendernden Anfrage.

FAQ zu API-Cookies

Was ist der Unterschied zwischen Cookie und Token in einer API?

Ein Cookie wird vom Browser automatisch angehaengt und verweist meist auf eine Server-Session, waehrend ein Bearer-Token manuell im Authorization-Header gesendet wird und oft in sich geschlossen ist. Cookies passen zu Web-Apps, Token zu mobilen und Service-Clients.

Sind Cookies fuer die API-Authentifizierung sicher?

Ja, bei korrekter Konfiguration. Setzen Sie HttpOnly, Secure sowie SameSite plus ein CSRF-Token. Ein Cookie ohne diese Flags ist ein echtes Risiko.

Was macht das SameSite-Attribut?

Es steuert, ob ein Cookie bei seitenuebergreifenden Anfragen gesendet wird. Strict nie, Lax nur bei Navigationen der obersten Ebene, None ueberall, aber nur mit Secure. Es ist der Hauptschutz gegen CSRF.

Warum bekommt mein API-Monitor einen 401, obwohl der Login klappt?

Meist speichert das Werkzeug das Session-Cookie nicht zwischen den Anfragen. Erfassen Sie das Set-Cookie aus der Login-Antwort und senden Sie es bei geschuetzten Aufrufen erneut, mit einer eigenen Cookie-Ablage pro virtuellem Nutzer.

Kann eine REST-API Cookies verwenden?

Ja, auch wenn eine per Cookie referenzierte Server-Session das Zustandslosigkeitsprinzip von REST lockert. Viele Teams nutzen Cookies fuer das Frontend und Bearer-Token fuer den programmatischen Zugriff.

Was unterscheidet ein Session-Cookie von einem persistenten Cookie?

Ein Session-Cookie hat kein Ablaufdatum und verschwindet am Sitzungsende, ein persistentes Cookie hat Expires oder Max-Age und bleibt bis dahin. Auth-Cookies sind meist kurzlebig, um das Risiko bei Diebstahl zu begrenzen.