An application gateway is a control point that sits between users or services and an application, inspecting traffic before it reaches the target system. In identity and security architecture, it can enforce authentication, authorization, session controls, and request filtering, helping reduce exposure while supporting secure access to web and API workloads.
What an application gateway does
An application gateway is an enforcement point, not just a routing hop. It inspects requests before they reach the application, so security decisions can be made at the edge of the app path rather than inside the workload itself.
That placement matters because it lets organisations centralise controls that would otherwise have to be repeated in each service, including user authentication, request validation, and session-aware access decisions. It is most useful when the goal is to reduce direct exposure of web or API backends while still allowing controlled access.
Security controls commonly enforced at the gateway
In practice, an application gateway may sit in front of a single application or a broader set of web and API services. It can terminate or enforce access policy before traffic is forwarded, which makes it a convenient point for standardising how requests are accepted, rejected, or forwarded.
Common controls include authentication checks, authorization decisions, session controls, request filtering, and sometimes rate-limiting or protocol normalisation. The security value comes from making those checks consistent at a shared choke point rather than leaving each backend to interpret traffic independently.
Where application gateways fit in the access path
Application gateways are often used when direct client-to-application exposure is too permissive for the environment. They can support architectures where users, services, and APIs must pass through a policy layer before any business logic is reached.
They are especially relevant when an application needs a controlled front door for internet-facing access, partner integration, or segmented internal access. In those cases, the gateway becomes part of the trust boundary, because it helps decide which requests are allowed to proceed and which are stopped early.
Why they matter for modern web and API workloads
Modern applications are usually composed of many endpoints, dependencies, and identities, so a gateway can reduce the blast radius of poor endpoint exposure. It is a useful pattern when teams want one place to enforce request inspection, policy decisions, and access rules across multiple workloads.
That said, a gateway is not a substitute for secure application design. If the backend still trusts every forwarded request without validating context, method, or caller intent, the gateway becomes only a partial control and may create a false sense of protection.
Risk and Threat Considerations
An application gateway can become a high-value control point because it concentrates access decisions, traffic inspection, and trust boundaries in one place. If it is misconfigured or bypassed, attackers may reach applications directly, evade policy checks, or exploit gaps between gateway rules and backend enforcement.
Failure mechanism: Weak filtering, broken authorization logic, exposed backend endpoints, or inconsistent session handling can let malicious requests pass through or skip the gateway entirely.
Impact: The result can be unauthorized access, request tampering, credential or session abuse, and broader exposure of web or API workloads than the organisation intended.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | Application gateways commonly enforce login and request-entry authentication controls. |
| V8 — Authorization | Gateways often make allow/deny decisions on user or service access to protected resources. | |
| V7 — Session Management | Gateways may inspect or protect session context used to control application access. | |
| Recommendation — Apply V6 to verify the gateway enforces strong authentication before requests reach the application. Apply V8 to ensure gateway authorization decisions match backend access policy. Apply V7 to validate that session handling remains secure across the gateway boundary. | ||
Practitioner Guidance
Why practitioners should care: An application gateway should be treated as part of the application security boundary, not merely as infrastructure plumbing. The design question is whether the gateway actually enforces policy that the backend can trust, or whether it is only observing traffic on the way through.
What to watch for: Confirm that direct backend paths are not left open, that authentication and authorization rules are consistent with application logic, and that logging makes gateway decisions auditable. For standards-based verification of request handling, authentication, and access control expectations, OWASP ASVS is a useful reference point, and PCI DSS v4.0 is relevant where gateway-enforced controls protect payment-related application access.
Related resources from NHI Mgmt Group
- Static Application Security Testing
- What is the difference between enforcing authorization in the gateway and in application code?
- When should organisations use gateway measurement instead of application measurement?
- How do organisations decide between gateway controls and application-level controls for APIs?