Media type of the body, optionally with a charset.
Content-Type: application/json; charset=utf-8
What to test
Assert responses declare the right type (application/json, application/problem+json for errors). Send requests with a wrong or missing Content-Type and expect 415. Error pages from proxies often come back as text/html.
Check export endpoints set attachment with a sensible filename, non-ASCII names use filename*, and user-supplied names cannot inject quotes or path separators.
Send Accept: application/xml to a JSON-only API: expect 406 or documented fallback. Versioned media types (application/vnd.example.v2+json) should select the right version.
Credentials for the request (Basic, Bearer, etc.).
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...
What to test
Test missing, malformed, expired and wrong-audience tokens (expect 401), and valid tokens lacking scope (expect 403). Make sure the header is not logged and not forwarded on cross-host redirects.
Responses with personal data or tokens must be no-store (or at least private). Public, cacheable resources should have a deliberate max-age. Check CDN behaviour matches.
Must not blindly reflect any Origin when credentials are allowed. "*" cannot be combined with credentials. Include Vary: Origin when the value depends on the request.
If the frontend reads Location, ETag or rate limit headers, they must be exposed; otherwise they appear null in the browser even though curl shows them.
Session cookies need Secure, HttpOnly and SameSite (Lax or Strict). SameSite=None requires Secure. Check Max-Age/Expires, Domain scope, and that logout clears the cookie.
Current remaining quota and reset time for a policy. IETF draft.
RateLimit: "default";r=42;t=30
What to test
Remaining (r) should decrease by one per request and the reset (t) should count down. Older drafts used separate RateLimit-Limit/-Remaining/-Reset headers.
Send a known trace id from your test and confirm it appears in the tracing backend, linking test failures to server traces. Malformed values must be ignored, not cause errors.
Retry the same request with the same key: one side effect, same response. Same key with a different body: expect 422 (or 409). Check how long keys are remembered.
Original client IP and protocol as seen by proxies.
X-Forwarded-For: 203.0.113.7, 10.0.0.2
What to test
Send a spoofed value directly and check rate limiting, IP allow-lists and audit logs do not trust it from untrusted hops.
RFC 7239 (Forwarded); X-Forwarded-For is de-facto
Über dieses Tool
Header tragen einen großen Teil des API-Verhaltens: Caching-Regeln, optimistisches Locking, CORS-Berechtigungen, Cookie-Sicherheit, Rate Limits und Trace-IDs. Diese Referenz listet knapp sechzig Header, die beim API-Testing vorkommen, jeweils mit Richtung, Zweck, einem realistischen Beispiel, Testideen und der zugrunde liegenden Spezifikation. Header, die noch IETF-Entwürfe sind, etwa RateLimit, RateLimit-Policy und Idempotency-Key, sind als Entwurf markiert, weil sich ihre Syntax noch ändern kann; verbreitete Konventionen ohne RFC wie X-Request-Id und X-RateLimit-* sind als De-facto-Standard markiert.
So funktioniert es
Suchen Sie nach einem Header oder Thema wie „cors“, „cookie“ oder „cache“.
Filtern Sie nach Richtung (Request oder Response) oder Kategorie.
Kopieren Sie die Beispielzeile in Ihren Request oder nutzen Sie den Hinweis „What to test“ (was testen) als Idee für eine Assertion. Jeder Header hat einen Ankerlink.
FAQ zu HTTP-Header-Referenz
Warum sieht curl einen Response-Header, mein Browser-Code aber nicht?
Cross-Origin-JavaScript kann nur CORS-freigegebene Response-Header lesen, sofern der Server weitere nicht in Access-Control-Expose-Headers auflistet. Location, ETag und eigene Header fehlen dort häufig.
Welche Security-Header sollte eine JSON-API senden?
Mindestens Strict-Transport-Security bei HTTPS und X-Content-Type-Options: nosniff, dazu Cache-Control: no-store bei Responses mit personenbezogenen Daten oder Tokens. Eine restriktive Content-Security-Policy ist eine günstige zusätzliche Härtung. Vermeiden Sie Versionsangaben in Server und X-Powered-By.
Unterscheiden Header-Namen Groß- und Kleinschreibung?
Nein. HTTP-Header-Namen sind case-insensitive, und HTTP/2 und HTTP/3 senden sie kleingeschrieben. Schreiben Sie Assertions, die Namen ohne Rücksicht auf Groß-/Kleinschreibung vergleichen; die meisten Clients, auch response.headers() in Playwright, normalisieren sie auf Kleinbuchstaben.