API headers and HTTP findings: what the response actually shows

Bind the finding to the correct response

A URL may return HTML without authentication and JSON with an appropriate token. A proxy may return its own error page before the request reaches the application. A redirect may lead to another host. ‘Header present’ and a domain name alone therefore do not suffice for interpretation.

For an existing finding on your own system, record these details together:

Do not share complete tokens, cookies or customer data. Joint diagnosis often needs only a sanitised excerpt of the affected headers and an internal, access-protected reference to the original.

Content-Type: identify the actual representation

Content-Type describes the representation's media type. application/json typically suits a JSON response, and application/problem+json a Problem Details document. An API may also serve a PDF, image, XML or text. ‘Not JSON’ therefore does not automatically mean ‘unsafe’. What matters is agreement between the contract, declared type and actual bytes. The basis is RFC 9110, section 8.3.

If a client receives HTML instead of expected JSON, do not blindly change the header to application/json. First investigate a login redirect, gateway error page or wrong path. An incorrect header does not repair content. Likewise, a syntactically correct type proves neither valid JSON nor permitted fields or correct data.

Special rules apply to responses without content. For example, a 204 No Content response contains no response content; a blanket ‘JSON header missing’ rule is inappropriate. HTTP semantics also matter for HEAD and 304 Not Modified. Do not create artificial bodies to satisfy a header check.

X-Content-Type-Options: nosniff complements the correct type in browser contexts. Among other effects, browsers block script or stylesheet use with an inappropriate MIME type; further effects depend on usage context. The header validates no JSON structure and prevents no unauthorised data disclosure. The web foundations for nosniff and MDN reference explain this browser behaviour.

Verification and rollback: after a change, test a successful response, a business error, rejected authentication and any intended download in your own test environment. Compare expected content and type. If a central header rule mislabels several response types, revert that rule and set types at the response that generates each one.

Cache-Control: distinguish public data from personal responses

Caching can reduce load on a deliberately public API. A public directory with identical content for everyone can be treated differently from a team's personal export list. Before deciding on caching, understand both data and cache: a private browser cache belongs to one client; a shared cache such as a CDN serves several.

For sensitive personal responses, Cache-Control: no-store is a useful starting rule when HTTP cache storage is unwanted. It is an instruction to caches, not access control or retrospective deletion of stored copies. Unqualified private prevents shared-cache storage but permits private storage under the remaining rules. no-cache generally means revalidation before reuse, not ‘store nothing’. Cache-Control explains general rules; RFC 9111 is normative.

The following excerpts are synthetic contract examples, not measured server responses:

# Personal export list: no storage in HTTP caches intended
Content-Type: application/json
Cache-Control: no-store

# Deliberately public directory, identical for everyone
Content-Type: application/json
Cache-Control: public, max-age=60

The second rule fits only if content, permission model and cache key actually suit this public use. The example's 60 seconds are no general recommendation. A response with individual fields does not become legitimately public data through the public header.

A common misconception concerns cookies: under HTTP caching rules, Set-Cookie alone does not prevent storage. A cache may treat these responses more strictly in its own configuration, but do not rely on that assumption without checking. A request with Authorization is not a universal caching prohibition either, because certain response directives can permit shared reuse. RFC 9111, sections 3.5 and 7.3.

Concrete test: in your isolated environment, use two accounts of your own with clearly distinguishable harmless data. Examine responses at the application server and through the actual test proxy. No response, cookie or personal field from the first account may appear for the second. Also check cache keys, bypass rules and error responses. A cache-hit header alone is not complete evidence; no hit header does not prove absence of caching.

If mixing occurs, stop the affected shared storage, preserve the necessary sanitised finding and investigate existing entries through your cache management. Reverting to a risky cache rule to restore performance is not safe rollback. Only a demonstrably separated or deliberately public representation permits re-enabling it.

Allow and OPTIONS: advertising is not authorisation

Allow lists HTTP methods advertised by the target. It is required in a 405 Method Not Allowed response. An OPTIONS response, however, need not always provide a complete method directory. Access-Control-Allow-Methods belongs to CORS and is another distinct statement. RFC 9110, sections 9.3.7 and 10.2.1.

If Allow contains DELETE, no delete call has thereby been executed and no unauthorised access proven. An application may need and correctly secure this method. Conversely, omitting it from a list does not prove the server rejects such calls. Check actual route/method mapping and function permissions with your own test data before removing methods indiscriminately.

TRACE in a list is likewise initially an advertisement. The Fetch Standard prohibits TRACE, TRACK and CONNECT as methods for corresponding browser calls. The often-repeated scenario of JavaScript reading session cookies through TRACE therefore does not automatically follow. An unnecessary diagnostic path remains a hardening concern; claiming actual data leakage needs other evidence. Fetch: Methods.

The HTTP property safe for GET or OPTIONS means the client requests no state change under the defined semantics. It does not guarantee a faulty server implementation has no side effects. Use even apparently harmless checks only in appropriate environments you own or are explicitly authorised to test. After a method change, intended clients, including preflights, must still work; correct the specific route rule on problems rather than enabling every method.

Server headers and CVE signals: assess installed packages, not banners

Server and X-Powered-By may hint at a technology involved. They may be absent, altered or describe the proxy instead of the application. A banner is therefore no reliable software inventory. HTTP recommends limiting unnecessarily precise product information, but removing a banner closes no vulnerability. RFC 9110, section 10.2.4.

A CVE identifies a published security issue. A version-string match warrants comparison: which package is actually installed, who maintains it, which configuration is affected, and is the fix already included? Some vendors incorporate security fixes into older version lines. Such a backport explains why an old visible version number alone does not prove vulnerability. Red Hat: Backporting Security Fixes.

The API Security Check uses a limited local CVE selection for certain recognisable product versions. It performs neither a complete current vulnerability comparison nor proof of exploitation. Without a usable version or suitable coverage, this question remains open. A missing match therefore justifies neither ‘everything up to date’ nor ‘no known vulnerabilities’.

Use the API inventory for actual versions and responsibilities. Targeted updates belong to operations: check relevant vendor notices, test changes in a suitable environment and prepare rollback that does not silently reintroduce the known defect.

Read measurement gaps and grades correctly

A failed or unanalysable probe is not a positive finding. A partial measurement may contain both a concrete match and open questions. A visible stack trace may remain relevant even if the rest of the response was truncated, for example. Conversely, unsearchable content says nothing about the absence of internal details.

Read an assessment in this order: target and context, measurement time and scope, concrete findings, measurement gaps, then the summary grade. The grade describes the limited assessment model. It answers neither the object-authorisation question nor whether your business flows are processed safely. Application acceptance needs suitable tests of your own.

The API Security Check can observe defined public response characteristics. It sends GET and OPTIONS plus a limited GET error probe; it examines no authenticated roles. Methods are read from declarations, rate limits are not proven under load, and responses are not certified as a comprehensively secure application. A report records that measurement without extending it.

Turn the finding into a verifiable change

Formulate a concrete expectation: ‘Our shared cache does not store the personal export list’ is more testable than ‘all headers green’. Name the responsible layer and preserve its previous configuration. Change a coherent rule, test the permitted normal case and relevant negative case, and record the actual effect.

If the observation does not fit the expected path, first clarify routing, authentication and proxy response. If permissions or business logic are involved, move to application tests and code review. The appropriate next step follows the unanswered question, not the number of conspicuous headers.

Next steps