Was sind API-Cookies?

Was sind API-Cookies?

API-Cookies sind kleine Datenstücke, die ein Server über HTTP-Antwort-Header beim Client setzt und die der Client bei späteren Anfragen an denselben Server zurückschickt. 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 ältesten und am weitesten verbreiteten Mechanismen, um Zustand zwischen Client und API zu halten.

Cookies sind für alle wichtig, die APIs bauen oder testen. Ein Login-Endpunkt antwortet oft mit einem Set-Cookie-Header, und jeder geschützte Endpunkt danach erwartet, dass das Cookie zurückkommt. 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 Rückweg über zwei HTTP-Header. Sendet ein Client eine Anfrage, kann der Server seiner Antwort einen Set-Cookie-Header anhängen. 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 zurück.

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 schlägt abc123 in seinem Session-Speicher nach, findet den zugehörigen Nutzer und autorisiert die Anfrage.

Session-Cookies und persistente Cookies

• Session-Cookies haben kein Expires- oder Max-Age-Attribut. Der Client behält sie nur bis zum Ende der Sitzung und verwirft sie dann. Ideal für 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 zurück. 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 größeres Risiko, falls es gestohlen wird.

Cookie-Attribute, die das Verhalten steuern

Attribut	Zweck
HttpOnly	Verhindert, dass JavaScript das Cookie über document.cookie liest, und begrenzt so den Schaden durch XSS.
Secure	Weist den Client an, das Cookie nur über HTTPS zu senden, also nie im Klartext.
SameSite	Steuert das Senden bei seitenübergreifenden 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	Beschränkt das Cookie auf URLs unter einem Pfadpräfix wie /api.
Expires / Max-Age	Legt fest, wann das Cookie gelöscht wird. Ohne Wert wird es ein Session-Cookie.

Das SameSite-Attribut verdient besondere Aufmerksamkeit. Strict hält das Cookie bei jeder Anfrage von einer anderen Seite zurück, Lax ist der moderne Standard und erlaubt es nur bei Navigationen der obersten Ebene, und None sendet es überall, 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 anhängt. Token-basierte Auth, etwa ein OAuth-2.0-Bearer-Token oder ein JSON Web Token (JWT), wird vom Client ausdrücklich im Authorization: Bearer <token>-Header gesendet.

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

Keiner der Ansätze ist grundsätzlich besser. Cookies glänzen bei First-Party-Web-Apps, weil HttpOnly das Credential vor Skripten schützt. Bearer-Token glänzen bei mobilen Clients und Service-zu-Service-Aufrufen.

CSRF-Überlegungen

Der Komfort von Cookies, dass der Browser sie automatisch anhängt, ist zugleich ihre Schwäche. Bei einem Cross-Site Request Forgery (CSRF)-Angriff löst eine böswillige Seite eine Anfrage an Ihre API aus, und der Browser fügt das Session-Cookie des Opfers pflichtbewusst hinzu. Setzen Sie SameSite=Lax oder Strict und ergänzen Sie ein CSRF-Token, das der Server ausstellt und der Client in einem Header echoen muss. Bearer-Token-APIs umgehen CSRF weitgehend, tragen dafür 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 Nötige 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 für das Web-Frontend und zustandslose Bearer-Token für 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 späteren Anfragen erneut senden. Die meisten HTTP-Bibliotheken bieten dafür eine Cookie-Ablage, und Werkzeuge wie curl haben die Flags --cookie-jar und --cookie.

Das ist direkt für Monitoring und Performance-Tests relevant. Ein API-Monitor, der einen eingeloggten Endpunkt prüft, muss zuerst den Login-Schritt ausführen, das zurückgegebene Session-Cookie behalten und beim geschützten Aufruf mitsenden, sonst meldet er einen 401 und alarmiert Sie wegen einer Störung, die es nicht gibt. Dasselbe gilt für 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 Abläufe in JMeter oder k6 skripten, sodass authentifizierte Wege wie beim echten Nutzer geprüft werden.

Best Practices und Sicherheit

• Setzen Sie immer HttpOnly auf Authentifizierungs-Cookies.
• Setzen Sie Secure und liefern Sie die API über HTTPS aus.
• Nutzen Sie SameSite=Lax als Basis und Strict für 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 zustandsändernden Anfrage.

FAQ zu API-Cookies

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

Ein Cookie wird vom Browser automatisch angehängt und verweist meist auf eine Server-Session, während 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 für 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 seitenübergreifenden Anfragen gesendet wird. Strict nie, Lax nur bei Navigationen der obersten Ebene, None überall, 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 geschützten 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 für das Frontend und Bearer-Token für 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.