Request and Response Headers

What Request and Response Headers Do in HTTP

Request and response headers are the metadata layer of HTTP. They carry details that shape how a client and server communicate, including content negotiation, authentication, caching, redirects, and security policy. Because headers influence behaviour before any application logic runs, they are often part of the first trust boundary an application must interpret correctly.

Request headers are not just transport decoration. They can affect routing, language selection, compression, proxy handling, and whether a request is treated as cross-site or same-site. Response headers can enforce browser behaviour, reduce data exposure, and tell intermediaries how to cache or transform content. That makes them foundational to web security as well as web operation.

Common Security Functions of Headers

Many security controls are implemented entirely through headers. Response headers such as Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, and related browser directives can reduce XSS impact, downgrade attacks, and content sniffing issues. Request headers such as Authorization, Origin, Referer, and the Fetch Metadata family help a server decide whether a request should be accepted and how much trust to place in it.

Headers also carry state and identity signals. Session cookies are set through response headers, while bearer tokens, API keys, or other authentication material may appear in request headers. If an application logs headers indiscriminately, forwards them across trust boundaries, or reflects them into responses, sensitive data can leak or be abused.

Header handling is therefore both a security control surface and an attack surface. A strong configuration can enforce safer browser behaviour and request validation, while weak parsing or inconsistent proxy handling can create security gaps that are easy to overlook during development.

How Headers Create Security and Reliability Risks

Header-based controls fail when the application, proxy, CDN, or browser interprets them differently. Misread cache headers can expose personalised content, weak redirect handling can be abused, and permissive cross-origin or origin-check logic can let hostile sites influence a trusted session. Incorrectly processed security headers can also undermine defences that teams believe are already in place.

Headers are especially dangerous when multiple intermediaries are involved. A reverse proxy may add, strip, merge, or rewrite fields in ways that change the meaning of the request or response. That is one reason web application attack guides often treat header manipulation, request smuggling, cache poisoning, and response splitting as closely related failure modes, rather than isolated bugs.

Web Application Attacks Guide is useful here because it covers request smuggling, response splitting, cache poisoning, and other header-driven attack patterns that exploit inconsistent parsing or trust in metadata fields.

Practical Examples of Header Misuse

A request header can be forged, copied from a browser session, or injected by a malicious client if the server trusts it too much. That matters for headers used in access checks, origin validation, client hints, or content routing. A response header can also be harmful if it reflects untrusted input, announces the wrong content type, or weakens browser protections by omission.

One particularly important case is cross-site request handling. Servers that rely on the Fetch Metadata family can reject unsafe requests based on the browser context, which reduces exposure to CSRF-style abuse and some cross-site data leaks. That only works if the application and its edge layers interpret those headers consistently.

Fetch Metadata and Resource Isolation Policy Guide explains how Sec-Fetch-* request headers can support stronger request filtering, fallback rules, and rollout discipline.

Practitioner Guidance

Why practitioners should care: Header logic sits at the junction of browsers, proxies, caches, and application code, so small mistakes can produce outsized security effects. Treat header handling as an enforceable policy layer, not a convenience feature.

What to watch for: Pay close attention to headers that influence authentication, origin trust, caching, redirects, and content handling. If different layers disagree about a header’s meaning, assume the safer interpretation has not yet been implemented.

Practitioner takeaway: Validate which headers you trust, which you generate, and which you must strip or normalise at every boundary, then verify the result in the browser and at the edge.

Related resources from NHI Mgmt Group

• What is the difference between SAML request signing and response encryption?
• Should organisations log every LLM request and response?
• When should teams choose response headers instead of meta tag CSP?
• Why do response headers fail in modern application delivery pipelines?