Was sind API-Cookies? Definition und Sicherheit

Was sind API-Cookies?

API-Cookies sind kleine Name-Wert-Paare, die ein API-Server mit einem Set-Cookie-Response-Header setzt und die der Client bei späteren Aufrufen an denselben Host im Cookie-Request-Header zurückschickt. Meistens enthält das Cookie eine undurchsichtige Session-ID, damit ein zustandsloser HTTP-Server einen angemeldeten Aufrufer erkennt, ohne bei jeder Anfrage Zugangsdaten zu verlangen.

Cookies spielen immer dann eine Rolle, wenn Sie eine authentifizierte API aufrufen oder testen. Verwirft ein Client, Monitor oder Lasttest-Skript das Cookie nach dem Login, scheitert jeder geschützte Aufruf mit 401, obwohl die API gesund ist.

So funktionieren Cookies mit APIs

Der Austausch läuft über zwei Header. Die Login-Antwort setzt das Cookie:

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

Der Client speichert es und sendet es bei jeder passenden Anfrage zurück. Mehrere Cookies stehen in einem Header, getrennt durch Semikolon und Leerzeichen:

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

Der Server schlägt abc123 im Session-Speicher nach, findet den Nutzer und autorisiert den Aufruf. Laut MDN-Referenz zu Set-Cookie ist ein Cookie ohne Expires und Max-Age ein Session-Cookie, das bis zum Beenden des Clients gilt. Sind beide gesetzt, hat Max-Age Vorrang. Der aktuelle Entwurf RFC 6265bis empfiehlt Browsern, die Lebensdauer auf 400 Tage zu begrenzen.

Wichtige Cookie-Attribute

SameSite=Strict hält das Cookie bei jeder Cross-Site-Anfrage zurück. Lax sendet es bei Top-Level-Navigationen mit sicherer Methode wie GET, aber nicht bei Cross-Site-Aufrufen im Hintergrund. Manche Browser wenden Lax an, wenn das Attribut fehlt. Setzen Sie es deshalb ausdrücklich, statt sich darauf zu verlassen. Cookie-Präfixe verschärfen die Regeln weiter: Ein __Host--Cookie muss Secure sein, Path=/ haben und darf keine Domain tragen.

Cookie-Auth oder Bearer-Token

APIs authentifizieren meist auf eine von zwei Arten. Bei Cookie-Auth (Session) liegt eine Session-ID in einem Cookie, das der Browser selbst anhängt. Token-Auth, etwa mit einem Bearer-Token oder JWT, überträgt das Token ausdrücklich im Authorization-Header.

Keines ist grundsätzlich besser, und viele Systeme nutzen beide. Ein langlebiger API-Schlüssel ist eine dritte Option für Server-zu-Server-Zugriff. Einen Überblick über Angriffe und Gegenmaßnahmen finden Sie unter API-Sicherheit.

CSRF: der Preis automatischer Cookies

Weil der Browser Cookies selbst anhängt, kann eine bösartige Seite den Browser des Opfers dazu bringen, eine Anfrage samt Session-Cookie an Ihre API zu senden. Das nennt sich Cross-Site Request Forgery (CSRF). Die Abwehr besteht aus mehreren Schichten: SameSite=Lax oder Strict, ein CSRF-Token, das der Client in einem Header oder Body-Feld zurücksenden muss, und die Prüfung des Origin-Headers bei zustandsändernden Anfragen. Bearer-Token-APIs umgehen CSRF weitgehend, dafür muss das Token sicher vor XSS gespeichert werden.

Cookies in API-Monitoring und Lasttests

Ein Werkzeug, das eine authentifizierte API aufruft, muss sich wie ein Browser verhalten: Set-Cookie aus der Login-Antwort erfassen, speichern und danach den passenden Cookie-Header senden. Die meisten HTTP-Bibliotheken bieten ein Cookie-Jar, und curl hat --cookie-jar und --cookie.

In einem Lasttest braucht jeder virtuelle Nutzer ein eigenes Cookie-Jar, gefüllt durch seinen eigenen Login, damit sich Sessions nicht überschneiden. Der HTTP Cookie Manager von JMeter führt für jeden Thread einen eigenen Cookie-Speicher, und LoadFocus führt Ihre vorhandenen JMX-Dateien in der Cloud aus, sodass dieses Setup erhalten bleibt. Bei tokenbasierten APIs kann das API-Monitoring von LoadFocus sich anmelden, das zurückgegebene Token an die nächste Anfrage weiterreichen und jeden Schritt prüfen. Seitengeschwindigkeits-Audits angemeldeter Seiten können mit dem Page-Speed-Monitoring ein Session-Cookie als eigenen Header senden. Mehr zu authentifizierten Testabläufen (englisch): OAuth2-Lasttests und realistische E-Commerce-Lastszenarien. Die Grundlagen von API-Prüfungen erklärt API-Testing.

Häufige Fehler

• Das Cookie nach dem Login im Skript oder Monitor verwerfen und dann einem Phantomausfall voller 401-Antworten hinterherjagen.
• Ein Cookie-Jar für alle virtuellen Nutzer teilen, sodass Tausende simulierte Nutzer wie eine einzige Session wirken.
• SameSite=None ohne Secure setzen: Browser lehnen das Cookie ab.
• Ein Secure-Cookie über reines HTTP testen, wo es nie gesendet wird (localhost ausgenommen).
• Nutzerdaten statt einer undurchsichtigen ID im Cookie ablegen oder Sessions wochenlang am Leben halten.
• Bei zustandsändernden Anfragen allein auf Cookies vertrauen, ohne CSRF-Token.

Häufige Fragen zu API-Cookies

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

Ein Cookie hängt der Browser automatisch an und es verweist meist auf eine serverseitige Session. Ein Bearer-Token wird ausdrücklich im Authorization-Header gesendet und ist oft selbstenthaltend. Cookies passen zu eigenen Web-Apps, Tokens zu mobilen Apps und Service-Clients.

Sind Cookies für die API-Authentifizierung sicher?

Sie können es sein, wenn sie richtig konfiguriert sind. Nutzen Sie HttpOnly gegen Skriptzugriff, Secure für HTTPS, SameSite plus CSRF-Token gegen gefälschte Anfragen und eine kurze Lebensdauer. Ein Cookie ohne diese Einstellungen ist ein echtes Risiko.

Was bewirkt das SameSite-Attribut?

Es steuert, ob ein Cookie bei Cross-Site-Anfragen gesendet wird. Strict sendet es nie cross-site, Lax nur bei Top-Level-Navigationen mit sicherer Methode, None überall, verlangt dafür aber Secure.

Warum bekommt mein API-Monitor oder Lasttest nach erfolgreichem Login ein 401?

Meist behält das Werkzeug das Session-Cookie nicht. Erfassen Sie Set-Cookie aus der Login-Antwort und senden Sie es bei jedem geschützten Aufruf mit, mit einem Cookie-Jar pro virtuellem Nutzer.

Kann eine REST-API Cookies verwenden?

Ja, aber eine serverseitige Session hinter einem Cookie lockert die Zustandslosigkeit von REST. Viele Teams nutzen Cookies für das Browser-Frontend und Bearer-Tokens für den programmatischen Zugriff.