Request context is the per-request data carrier used in Go to pass deadlines, cancellation, and identity information through the application. For authentication, it usually holds the authenticated subject after middleware runs, and it must be keyed carefully to avoid collisions.
Expanded Definition
Request context is the per-request state carrier that lets a Go application move cancellation signals, deadlines, and request-scoped identity through middleware and downstream handlers. In NHI and IAM workflows, it often becomes the temporary place where an authenticated subject, tenant, or authorization decision is attached after verification.
Definitions vary across vendors and engineering teams when request context is extended beyond transport concerns into application state. The practical boundary is clear: it should carry only data tied to the life of the request, not long-lived secrets, cached permissions, or business objects that outlive the call. For identity systems, that distinction matters because request context is a delivery mechanism, not an identity store. The Go documentation and broader guidance around context propagation align with the operational discipline described in the NIST Cybersecurity Framework 2.0, where control of session-scoped access and reliable cancellation both support secure service behavior.
The most common misapplication is storing authentication state or credentials in request context as a permanent source of truth, which occurs when developers use it for convenience instead of limiting it to request-scoped propagation.
Examples and Use Cases
Implementing request context rigorously often introduces tighter coding discipline and more explicit dependency passing, requiring organisations to weigh clean request tracing against the convenience of global state.
- A login middleware validates a bearer token, extracts the subject, and stores only the verified identity claim in request context so downstream handlers can authorize the action without re-parsing headers.
- An API gateway attaches tenant information and a deadline to request context, allowing each service in the chain to enforce isolation and stop processing when the client disconnects.
- A background job dispatcher receives an incoming request, copies only the cancellation signal into a worker call, and avoids persisting transient user data beyond the request lifecycle.
- An internal service looks up a service account or agent identity once, then uses request context for policy checks while preserving the stronger controls described in the Ultimate Guide to NHIs.
- A microservice chain uses context values for correlation IDs and request-scoped subject mapping, while relying on the NIST Cybersecurity Framework 2.0 to keep access decisions auditable and bounded.
These patterns are useful only when the values are small, transient, and directly related to the active request. Once teams start embedding broad authorization graphs or mutable session records, request context becomes harder to reason about and easier to misuse.
Why It Matters in NHI Security
Request context is small, but its security impact is outsized because it often becomes the handoff point between identity verification and authorization enforcement. If middleware populates the wrong subject, or if later code trusts an unvalidated context value, the application can silently authorize the wrong NHI, agent, or service account. That is especially dangerous in automated systems where actions are executed at machine speed and errors propagate across multiple services.
This matters in real NHI programs because identity sprawl already creates a large attack surface: Ultimate Guide to NHIs reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. Request context is not the root cause of those breaches, but it is often where compromised or malformed identity data is first trusted inside the application. That is why it should be treated as a short-lived carrier in a broader control model that also includes NIST Cybersecurity Framework 2.0 practices for access control, monitoring, and response.
Organisations typically encounter request-context failures only after a privilege escalation, audit discrepancy, or production incident reveals that the wrong identity was attached to a request, at which point the concept 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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secure handling of identities and secrets in request-scoped flows. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access enforcement and identity-based control decisions in services. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification, not trust in ambient request state. |
Keep request context free of secrets and verify only the minimum identity data needed for the call.
