A custom HTTP header is an application-defined field added to a request or response outside standard protocol headers. Teams sometimes use it to pass session data, metadata, or routing signals. It becomes a security risk when logs, proxies, or export tools fail to recognise it as sensitive.
Expanded Definition
A custom HTTP header is an application-defined request or response field that extends standard HTTP metadata with environment-specific information. In NHI and agentic systems, teams use these headers to carry routing hints, request correlation values, tenancy markers, or workflow context that downstream services need to process traffic correctly.
Definitions vary across vendors on whether a header is “custom” only when it uses a nonstandard name, or also when it carries nonstandard semantics. The security issue is not the header itself but the data classification and trust boundary around it. A custom header can become a control plane signal, a cache key, or an identity-adjacent attribute, which means it may influence authorisation decisions, logging, and observability. That places it squarely within governance concerns covered by the NIST Cybersecurity Framework 2.0 when it is used to shape access or processing paths.
The most common misapplication is treating a custom header as harmless application metadata, which occurs when teams allow sensitive tokens, session state, or trust assertions to move through intermediaries without validation or redaction.
Examples and Use Cases
Implementing custom HTTP headers rigorously often introduces coordination overhead, requiring organisations to weigh routing flexibility and traceability against the risk of header leakage, spoofing, or inconsistent handling across proxies and services.
- API gateways pass an internal tenant identifier in a custom header so backend services can isolate requests without rewriting application payloads.
- Microservices add a request correlation header to trace calls across distributed logs, but the value must be treated as operational metadata, not a security control.
- Agentic workflows include a tool-invocation context header to tell downstream services which AI agent or job initiated the request, especially when paired with NHI governance patterns described in the Ultimate Guide to NHIs.
- Legacy integrations use headers for feature flags or routing decisions when payload changes are expensive, but those headers should be validated like any other input.
- Security teams use a custom header to mark requests that originated from a trusted internal system, while ensuring downstream enforcement still relies on cryptographic identity and not the header alone.
When custom headers are used to support identity-aware routing, the implementation should be mapped to known HTTP handling guidance such as the HTTP Semantics RFC 9110 and tested across every proxy, CDN, and service boundary that may drop or rewrite fields.
Why It Matters in NHI Security
Custom headers matter because they often carry context that downstream systems use to infer trust, identity, or workflow state. If that context is spoofed, duplicated, or logged without protection, a non-human identity can inherit permissions or routing advantages it should never have. The risk is amplified when headers are mistaken for internal-only signals and allowed to bypass normal authentication or secret-handling controls.
NHI Mgmt Group research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which illustrates how easily control data can spill into places it should not. The same pattern applies to headers: once a value is embedded in logs, exports, or debugging tools, it becomes much harder to govern. This is especially relevant to service-to-service systems that follow Zero Trust principles and the NIST Cybersecurity Framework 2.0 for access control and logging discipline. For broader NHI context, the Ultimate Guide to NHIs is the clearest reference point.
Organisations typically encounter custom-header risk only after a header has been replayed, logged, or trusted during an incident, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Custom headers can carry sensitive NHI context that must not be treated as harmless metadata. |
| NIST CSF 2.0 | PR.AC-4 | Header-based routing and trust signals affect access enforcement and least-privilege decisions. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires verification at every boundary where headers may be altered or replayed. |
| OWASP Agentic AI Top 10 | A2 | Agentic systems may use headers for tool context, creating spoofing and prompt-routing risks. |
| NIST AI RMF | AI systems using headers for context need governance around transparency, validity, and misuse. |
Classify header values, prevent secret-like data in headers, and validate all downstream handling.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
