Pular para o conteúdo
SDETRole
SDETRole

Testes de API

Referência de headers HTTP

Headers de requisição e resposta que importam ao testar APIs.

Roda inteiramente no seu navegador Sem cadastro

59 of 59 headers

Content-Type

Request + responseContent

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.

RFC 9110 §8.3

Content-Length

Request + responseContent

Size of the body in bytes.

Content-Length: 348

What to test

Must match the actual byte length (multi-byte UTF-8 characters count as more than one). 204 and 304 responses carry no body.

RFC 9110 §8.6

Content-Encoding

Request + responseContent

Compression applied to the body (gzip, br, zstd).

Content-Encoding: gzip

What to test

Send Accept-Encoding: gzip and verify the response is compressed and decodes correctly; without it, the response must not be compressed.

RFC 9110 §8.4

Content-Disposition

ResponseContent

Whether to display inline or download as an attachment, and the file name.

Content-Disposition: attachment; filename="report.csv"; filename*=UTF-8''r%C3%A9sum%C3%A9.csv

What to test

Check export endpoints set attachment with a sensible filename, non-ASCII names use filename*, and user-supplied names cannot inject quotes or path separators.

RFC 6266

Content-Language

ResponseContent

Natural language of the response content.

Content-Language: de-DE

What to test

For localised APIs, confirm it matches the language negotiated from Accept-Language.

RFC 9110 §8.5

Accept

RequestContent

Media types the client can handle.

Accept: application/json

What to test

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.

RFC 9110 §12.5.1

Accept-Encoding

RequestContent

Compression formats the client supports.

Accept-Encoding: gzip, br

What to test

Verify large responses are compressed when requested. curl needs --compressed to send this and decode the result.

RFC 9110 §12.5.3

Accept-Language

RequestContent

Preferred languages for the response.

Accept-Language: fr-CH, fr;q=0.9, en;q=0.8

What to test

Check error messages and localised fields follow the preference, with a sensible default for unsupported languages.

RFC 9110 §12.5.4

Range

RequestContent

Request only part of a resource.

Range: bytes=0-1023

What to test

Expect 206 with matching Content-Range; an out-of-bounds range should give 416.

RFC 9110 §14.2

Content-Range

ResponseContent

Which part of the resource a 206 response contains.

Content-Range: bytes 0-1023/146515

What to test

Validate start, end and total; resumable downloads depend on the total being correct.

RFC 9110 §14.4

Prefer

RequestContent

Client preferences such as return=minimal or respond-async.

Prefer: return=representation

What to test

If supported, compare responses with return=minimal vs return=representation and check Preference-Applied in the response.

RFC 7240

Authorization

RequestAuth

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.

RFC 9110 §11.6.2

WWW-Authenticate

ResponseAuth

Sent with 401 to describe how to authenticate.

WWW-Authenticate: Bearer realm="api", error="invalid_token"

What to test

Every 401 should include it. For OAuth bearer tokens, error="invalid_token" or "insufficient_scope" helps clients react correctly (RFC 6750).

RFC 9110 §11.6.1

X-API-Key

RequestAuthde-facto

Common custom header for API keys.

X-API-Key: sk_test_51H...

What to test

Check invalid and revoked keys are rejected, keys are scoped per environment, and keys sent in query strings (if allowed) do not appear in logs.

Convention (no RFC)

Cache-Control

Request + responseCaching

Caching directives: max-age, no-cache, no-store, private, public.

Cache-Control: no-store

What to test

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.

RFC 9111 §5.2

ETag

ResponseCaching

Opaque version identifier of a representation.

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

What to test

Same content, same ETag; changed content, new ETag. Use it with If-None-Match (expect 304) and If-Match (expect 412 when stale).

RFC 9110 §8.8.3

Last-Modified

ResponseCaching

When the resource last changed.

Last-Modified: Tue, 03 Nov 2026 08:12:31 GMT

What to test

Must be an IMF-fixdate in GMT and must change when the resource changes.

RFC 9110 §8.8.2

Expires

ResponseCaching

Absolute expiry time; ignored when Cache-Control max-age is present.

Expires: Wed, 04 Nov 2026 08:00:00 GMT

What to test

Check it does not contradict Cache-Control. An invalid date (e.g. "0") means already expired.

RFC 9111 §5.3

Age

ResponseCaching

Seconds the response has been in a shared cache.

Age: 120

What to test

Presence means a cache (CDN) served the response. Useful to confirm whether a stale result came from cache.

RFC 9111 §5.1

Vary

ResponseCaching

Request headers that change the response, so caches key on them.

Vary: Accept-Encoding, Authorization

What to test

If responses differ by Authorization, Accept or Accept-Language, those must be listed or a cache can serve one user's response to another.

RFC 9110 §12.5.5

If-None-Match

RequestConditional

Conditional GET: only return the body if the ETag changed.

If-None-Match: "33a64df5"

What to test

Matching ETag returns 304 with no body; a different ETag returns 200. With "*" on PUT, it prevents overwriting an existing resource (expect 412).

RFC 9110 §13.1.2

If-Match

RequestConditional

Only apply the update if the resource still has this ETag (optimistic locking).

If-Match: "33a64df5"

What to test

Update with a stale ETag and expect 412 with no change. If the API requires it, omitting it should give 428.

RFC 9110 §13.1.1

If-Modified-Since

RequestConditional

Conditional GET based on Last-Modified.

If-Modified-Since: Tue, 03 Nov 2026 08:12:31 GMT

What to test

Expect 304 when unchanged. Ignored when If-None-Match is also sent.

RFC 9110 §13.1.3

Origin

RequestCORS

Origin of the page making a cross-origin (or POST) request.

Origin: https://app.example.com

What to test

Send requests with an untrusted Origin and check the response does not grant it access. Also used for CSRF checks on cookie-authenticated APIs.

RFC 6454; Fetch Standard

Access-Control-Allow-Origin

ResponseCORS

Which origin may read the response in a browser.

Access-Control-Allow-Origin: https://app.example.com

What to test

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.

Fetch Standard (CORS)

Access-Control-Allow-Credentials

ResponseCORS

Whether the browser may send/expose cookies and auth on cross-origin requests.

Access-Control-Allow-Credentials: true

What to test

If true, Allow-Origin must be a specific trusted origin. Reflected origin + credentials is a critical misconfiguration.

Fetch Standard (CORS)

Access-Control-Allow-Methods

ResponseCORS

Methods allowed for the actual request, sent in preflight responses.

Access-Control-Allow-Methods: GET, POST, PATCH

What to test

Send an OPTIONS preflight with Access-Control-Request-Method and check only intended methods are listed.

Fetch Standard (CORS)

Access-Control-Allow-Headers

ResponseCORS

Request headers allowed on the actual request.

Access-Control-Allow-Headers: Authorization, Content-Type, Idempotency-Key

What to test

Custom headers your frontend sends (Authorization, Idempotency-Key, traceparent) must be listed or the browser blocks the call.

Fetch Standard (CORS)

Access-Control-Expose-Headers

ResponseCORS

Response headers that browser JavaScript may read.

Access-Control-Expose-Headers: Location, ETag, X-Request-Id

What to test

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.

Fetch Standard (CORS)

Access-Control-Max-Age

ResponseCORS

How long the browser may cache a preflight result, in seconds.

Access-Control-Max-Age: 600

What to test

Check it is set to avoid a preflight before every request; browsers cap the value.

Fetch Standard (CORS)

Access-Control-Request-Method

RequestCORS

Sent by the browser in an OPTIONS preflight to ask whether a method is allowed.

Access-Control-Request-Method: DELETE

What to test

Simulate preflights with curl -X OPTIONS plus Origin and this header; expect 204/200 with the Allow-* headers.

Fetch Standard (CORS)

Access-Control-Request-Headers

RequestCORS

Sent in a preflight to ask whether custom headers are allowed.

Access-Control-Request-Headers: authorization, content-type

What to test

Pair with Access-Control-Allow-Headers checks in the preflight response.

Fetch Standard (CORS)

Strict-Transport-Security

ResponseSecurity

Tells browsers to use HTTPS only for this host (HSTS).

Strict-Transport-Security: max-age=31536000; includeSubDomains

What to test

Present on HTTPS responses with a long max-age (at least six months). Plain HTTP should redirect to HTTPS.

RFC 6797

Content-Security-Policy

ResponseSecurity

Restricts what a page can load and execute; mitigates XSS.

Content-Security-Policy: default-src 'none'; frame-ancestors 'none'

What to test

For JSON APIs a restrictive policy like default-src 'none' is cheap hardening. For HTML, check there is no 'unsafe-inline' script-src without nonces.

W3C CSP Level 3

X-Content-Type-Options

ResponseSecurity

nosniff stops browsers guessing a different content type.

X-Content-Type-Options: nosniff

What to test

Should be present on every response, especially those returning user-controlled content.

Fetch Standard

X-Frame-Options

ResponseSecurity

Prevents the page being framed (clickjacking).

X-Frame-Options: DENY

What to test

For HTML responses, check DENY/SAMEORIGIN or CSP frame-ancestors is set.

RFC 7034 (superseded by CSP frame-ancestors)

Referrer-Policy

ResponseSecurity

Controls how much of the URL is sent in Referer.

Referrer-Policy: strict-origin-when-cross-origin

What to test

Make sure URLs with tokens or ids are not leaked to third parties via Referer.

W3C Referrer Policy

Permissions-Policy

ResponseSecurity

Enables or disables browser features (camera, geolocation...).

Permissions-Policy: camera=(), geolocation=()

What to test

For web apps, check unused powerful features are disabled.

W3C Permissions Policy

Server

ResponseSecurity

Describes the origin server software.

Server: nginx

What to test

Detailed versions (nginx/1.18.0, Apache/2.4.41 (Ubuntu)) help attackers; check they are suppressed.

RFC 9110 §10.2.4

X-Powered-By

ResponseSecurityde-facto

Framework banner added by some stacks (Express, PHP, ASP.NET).

X-Powered-By: Express

What to test

Should be removed in production; it discloses the technology stack.

Convention (no RFC)

Location

ResponseRedirects

Target of a redirect, or the URI of a resource created by 201.

Location: /v1/orders/8812

What to test

For 201, GET the Location and compare with what was created. For 3xx, make sure it cannot be controlled by a user parameter (open redirect).

RFC 9110 §10.2.2

Allow

ResponseRedirects

Methods supported by the resource; required with 405.

Allow: GET, HEAD, PUT

What to test

Every 405 should carry Allow, and it should match what actually works.

RFC 9110 §10.2.1

Retry-After

ResponseRate limiting

How long to wait before retrying (seconds or HTTP date).

Retry-After: 30

What to test

Expected with 429 and 503. Verify clients honour it and that requests succeed after the delay.

RFC 9110 §10.2.3

RateLimit-Policy

ResponseRate limitingIETF draft

Describes the quota policy (limit and window). IETF draft: syntax has changed between draft versions.

RateLimit-Policy: "default";q=100;w=60

What to test

If the API implements the draft, check values match the documented quota. Pin your assertions to the draft version the API claims to follow.

IETF draft-ietf-httpapi-ratelimit-headers

RateLimit

ResponseRate limitingIETF draft

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.

IETF draft-ietf-httpapi-ratelimit-headers

X-RateLimit-Limit / -Remaining / -Reset

ResponseRate limitingde-facto

Widely used non-standard rate limit headers.

X-RateLimit-Remaining: 57

What to test

Check Reset semantics (epoch seconds vs seconds remaining) are documented and consistent, and Remaining reaches 0 exactly when 429 starts.

Convention (no RFC)

Deprecation

ResponseLifecycle

Signals that the endpoint is (or will be) deprecated, as a structured date.

Deprecation: @1798761600

What to test

Deprecated endpoints should send it, ideally with a Link rel="deprecation" to docs, so client teams get warned automatically.

RFC 9745

Sunset

ResponseLifecycle

When the resource is expected to stop working.

Sunset: Thu, 31 Dec 2026 23:59:59 GMT

What to test

Check the date is valid and that after it the API returns 410 or a documented error.

RFC 8594

X-Request-Id

Request + responseTracingde-facto

Correlation id to find a request in logs.

X-Request-Id: 7f3c2a9e-1b44-4c1d-9f0e-2d8a6b1c5e77

What to test

Responses (including errors) should return one; if the client sends one, it should be echoed or linked. Put it in bug reports.

Convention (no RFC)

traceparent

RequestTracing

Distributed tracing context: version-traceid-parentid-flags.

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

What to test

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.

W3C Trace Context

tracestate

RequestTracing

Vendor-specific trace data accompanying traceparent.

tracestate: vendor1=opaqueValue

What to test

Should be propagated unchanged by services that do not understand it.

W3C Trace Context

Idempotency-Key

RequestReliabilityIETF draft

Client-generated key so retried POST/PATCH requests are applied once. IETF draft; widely implemented by payment APIs.

Idempotency-Key: "8e03978e-40d5-43e8-bc93-6894a57f9324"

What to test

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.

IETF draft-ietf-httpapi-idempotency-key-header

Host

RequestContext

Target host and port; required in HTTP/1.1.

Host: api.example.com

What to test

Send a forged Host and check it is not used to build links in emails or redirects (host header injection).

RFC 9110 §7.2

User-Agent

RequestContext

Identifies the client software.

User-Agent: checkout-tests/1.4 (+https://example.com)

What to test

Make API test traffic identifiable. Some WAFs block default library user agents, which can cause confusing 403s in CI.

RFC 9110 §10.1.5

Referer

RequestContext

URL of the page that made the request (historic misspelling).

Referer: https://app.example.com/checkout

What to test

Should not be the only CSRF defence. Check URLs containing secrets are not sent to third parties.

RFC 9110 §10.1.3

Forwarded / X-Forwarded-For

RequestContext

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

Sobre esta ferramenta

Os headers carregam boa parte do comportamento de uma API: regras de cache, locking otimista, permissões de CORS, segurança de cookies, rate limits e trace ids. Esta referência lista perto de sessenta headers que aparecem em testes de API, cada um com direção, finalidade, um exemplo realista, o que testar e a especificação que o define. Headers que ainda são drafts do IETF, como RateLimit, RateLimit-Policy e Idempotency-Key, são marcados como draft porque a sintaxe ainda pode mudar; convenções muito usadas sem RFC, como X-Request-Id e X-RateLimit-*, são marcadas como padrão de fato.

Como usar

  1. Busque um header ou um tema como “cors”, “cookie” ou “cache”.
  2. Filtre por direção (requisição ou resposta) ou por categoria.
  3. Copie a linha de exemplo para a sua requisição ou use a nota “O que testar” como ideia de assertion. Cada header tem um link âncora.

Perguntas frequentes: Referência de headers HTTP

Por que o curl vê um header de resposta e meu código no navegador não?

JavaScript cross-origin só consegue ler headers de resposta na safelist do CORS, a menos que o servidor liste outros em Access-Control-Expose-Headers. Location, ETag e headers customizados costumam ficar de fora dessa lista.

Quais headers de segurança uma API JSON deve enviar?

No mínimo Strict-Transport-Security em HTTPS e X-Content-Type-Options: nosniff, além de Cache-Control: no-store em respostas com dados pessoais ou tokens. Uma Content-Security-Policy restritiva é um reforço extra barato. Evite expor versões em Server e X-Powered-By.

Os nomes de headers diferenciam maiúsculas de minúsculas?

Não. Os nomes de campos de header HTTP não diferenciam maiúsculas de minúsculas, e HTTP/2 e HTTP/3 os enviam em minúsculas. Escreva assertions que comparem nomes sem diferenciar maiúsculas; a maioria dos clientes, incluindo response.headers() do Playwright, normaliza para minúsculas.

Digite para buscar em todo o SDETRole.

Busca de texto completo com Pagefind · roda no seu navegador Abrir página de busca →