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
À propos de cet outil
Les en-têtes portent une grande partie du comportement d’une API : règles de cache, verrouillage optimiste, permissions CORS, sécurité des cookies, rate limits et identifiants de trace. Cette référence liste près de soixante en-têtes qu’on croise en test d’API, chacun avec son sens (requête ou réponse), son rôle, un exemple réaliste, ce qu’il faut tester et la spécification qui le définit. Les en-têtes encore au stade de brouillon IETF, comme RateLimit, RateLimit-Policy et Idempotency-Key, sont signalés comme tels car leur syntaxe peut encore changer ; les conventions répandues sans RFC, comme X-Request-Id et X-RateLimit-*, sont marquées « de-facto ».
Mode d’emploi
Recherchez un en-tête ou un thème comme « cors », « cookie » ou « cache ».
Filtrez par sens (requête ou réponse) ou par catégorie.
Copiez la ligne d’exemple dans votre requête, ou utilisez la note « What to test » (à tester) comme idée d’assertion. Chaque en-tête a un lien d’ancre.
FAQ : Référence des en-têtes HTTP
Pourquoi curl voit-il un en-tête de réponse que mon code dans le navigateur ne voit pas ?
Le JavaScript cross-origin ne peut lire que les en-têtes de réponse autorisés par CORS (safelisted), sauf si le serveur en liste d’autres dans Access-Control-Expose-Headers. Location, ETag et les en-têtes personnalisés y manquent souvent.
Quels en-têtes de sécurité une API JSON doit-elle envoyer ?
Au minimum Strict-Transport-Security en HTTPS et X-Content-Type-Options: nosniff, plus Cache-Control: no-store sur les réponses contenant des données personnelles ou des tokens. Une Content-Security-Policy restrictive est un durcissement supplémentaire peu coûteux. Évitez d’exposer des versions dans Server et X-Powered-By.
Les noms d’en-têtes sont-ils sensibles à la casse ?
Non. Les noms de champs d’en-tête HTTP sont insensibles à la casse, et HTTP/2 et HTTP/3 les envoient en minuscules. Écrivez des assertions qui comparent les noms sans tenir compte de la casse ; la plupart des clients, dont response.headers() de Playwright, les normalisent en minuscules.