The access phase is the point in Kong Gateway request processing where routing is already known and the plugin can still modify the request before it is sent upstream. It is the right phase for header enrichment, request validation, and policy enforcement that must happen before proxying.
What the Access Phase Does in a Gateway Pipeline
The access phase is where a gateway has already chosen a route and can still shape the request before it reaches the upstream service. That makes it a control point for enforcing policy, rejecting unsafe input, and adding trusted metadata at the edge of the trust boundary.
Because the route is known at this stage, the logic is more precise than an earlier generic filter phase. This is why teams use the access phase for checks that depend on route context, target service, request attributes, or policy decisions that should happen before proxying.
Why It Matters for Request Processing
The access phase sits in the narrow window between routing and upstream forwarding, so any decision made here directly affects what the backend receives. That gives it a practical role in reducing unnecessary backend exposure, centralising policy enforcement, and keeping request handling consistent across services.
Common uses include header enrichment, allow or deny decisions, input validation, and normalization of request attributes. In practice, that means the phase is often used to enforce controls that should run once the destination is known, rather than duplicating the same logic in every upstream application.
Typical Controls Applied at This Stage
Access-phase controls usually focus on request admissibility and trust shaping. A plugin may validate headers, inspect parameters, apply policy based on the route, or rewrite request details so the upstream service sees a cleaner and more predictable request.
This phase is also where teams can attach security-relevant context, such as identity or tenancy markers, provided that the gateway is the right place to assert them. The key distinction is that these actions are pre-upstream transformations, not post-response handling and not low-level transport setup.
How It Differs from Other Gateway Phases
The access phase is not the same as early request lifecycle hooks that run before routing is resolved, and it is not the place for response filtering or logging after the request has already been sent. Its purpose is to act on a request once the gateway knows where it is going, but before the upstream sees it.
That positioning is what makes the phase useful for policy enforcement that depends on route selection. If a control needs target-specific context, the access phase is usually the right place to implement it; if it needs request-body inspection after full buffering or response transformation, another phase is more appropriate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Access-phase policy enforcement controls what request data reaches the upstream service. |
| SI-10 — Information Input Validation | Access-phase request validation maps directly to validating inputs before forwarding. | |
| Recommendation — Enforce AC-4 at the gateway to block or shape requests before they flow to backend services. Apply SI-10 to validate request content at the gateway before proxying upstream. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Gateway request handling can depend on trusted transport and protected request attributes where applicable. |
| Recommendation — Use A.8.24 to protect sensitive request data when gateway processing relies on cryptographic safeguards. | ||
| OWASP ASVS | V8 — Authorization | Route-aware enforcement at the access phase commonly implements authorization decisions before an upstream call. |
| V2 — Validation and Business Logic | Access-phase validation of request fields and headers aligns with ASVS validation requirements. | |
| Recommendation — Use V8 to ensure gateway-side access checks are enforced consistently before requests reach the application. Use V2 to validate request data at the gateway before it is processed by downstream services. | ||
Practitioner Guidance
Governance implication: Treat access-phase logic as part of the gateway’s enforcement boundary, not as application decoration. If a rule is meant to protect multiple upstream services consistently, placing it here reduces drift and makes the control easier to audit.
What to watch for: Keep the phase focused on pre-upstream decisions that truly need route awareness. Overloading it with business logic, response concerns, or late-stage transformations makes the pipeline harder to reason about and can blur ownership between gateway and application teams.
Related resources from NHI Mgmt Group
- How should security teams phase out SMS OTP without breaking access?
- How should security teams phase out passwords without breaking access?
- How should organisations phase in passwordless authentication without disrupting access?
- How should organisations phase an IGA programme without creating more access drift?
