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
Acerca de esta herramienta
Las cabeceras concentran gran parte del comportamiento de una API: reglas de caché, bloqueo optimista, permisos CORS, seguridad de cookies, rate limits e ids de traza. Esta referencia recoge cerca de sesenta cabeceras que aparecen en las pruebas de API, cada una con su dirección, su propósito, un ejemplo realista, qué probar y la especificación que la define. Las cabeceras que siguen siendo borradores del IETF, como RateLimit, RateLimit-Policy e Idempotency-Key, están marcadas como borradores porque su sintaxis aún puede cambiar; las convenciones muy extendidas sin RFC, como X-Request-Id y X-RateLimit-*, están marcadas como estándar de facto.
Cómo usarla
Busca una cabecera o un tema como «cors», «cookie» o «cache».
Filtra por dirección (petición o respuesta) o por categoría.
Copia la línea de ejemplo en tu petición, o usa la nota “What to test” como idea para una assertion. Cada cabecera tiene un enlace ancla.
Preguntas frecuentes: Referencia de cabeceras HTTP
¿Por qué curl ve una cabecera de respuesta pero mi código en el navegador no?
El JavaScript cross-origin solo puede leer las cabeceras de respuesta incluidas en la lista segura de CORS, salvo que el servidor declare otras en Access-Control-Expose-Headers. Location, ETag y las cabeceras personalizadas suelen faltar en ella.
¿Qué cabeceras de seguridad debe enviar una API JSON?
Como mínimo Strict-Transport-Security en HTTPS y X-Content-Type-Options: nosniff, además de Cache-Control: no-store en las respuestas que contengan datos personales o tokens. Una Content-Security-Policy restrictiva es un refuerzo extra barato. Evita revelar versiones en Server y X-Powered-By.
¿Los nombres de cabecera distinguen mayúsculas y minúsculas?
No. Los nombres de los campos de cabecera HTTP no distinguen mayúsculas, y HTTP/2 y HTTP/3 los envían en minúsculas. Escribe assertions que comparen los nombres sin distinguir mayúsculas; la mayoría de los clientes, incluido response.headers() de Playwright, los normalizan a minúsculas.