Both matter, but endpoint-level checks should not depend on the gateway alone. Gateways centralise policy and visibility, yet broken object-level authorisation and token misuse are enforced where the API executes the request. The safer approach is to treat the gateway as one control point and the endpoint as the final decision point.
Where the Gateway Helps and Where It Cannot Decide
The gateway is valuable because it can centralise routing, policy enforcement, rate limits, schema validation, and logging across many consumers. It is the right place to standardise coarse controls that should be consistent for every request. But it is not the final authority on whether a caller may read or change a specific object, because that decision often depends on business context only the endpoint can evaluate.
That distinction matters in API design. Gateway controls reduce exposure, but they do not eliminate the need for the service to re-check who the caller is, what token it presented, and whether that token is allowed to perform the requested action on the requested resource. If the endpoint trusts the gateway implicitly, the service inherits every gap that reaches it.
Why Endpoint-Level Checks Still Carry the Real Authorization Burden
Endpoint-level checks are where object ownership, tenant scope, function-level permission, and request-specific validation should be enforced. This is the layer that can distinguish between a request that is syntactically valid and one that is actually authorised for that user, workload, or token. That is why broken object-level authorization remains a service-side defect even when the gateway is well configured.
OWASP API Security Top 10 is directly relevant here because broken authorisation and related API failures are frequently endpoint problems, not gateway problems. A gateway may verify a token and pass the request onward, but the endpoint must still bind the token to the specific object, action, and scope being requested.
This is also why token handling should be treated as part of the request path, not just the perimeter. A valid token can still be misused if the service accepts it without checking whether its claims and scopes align with the exact operation being attempted.
The Practical Division of Labour Between Gateway Policy and Service Logic
The cleanest pattern is to use the gateway for broad, repeatable controls and the endpoint for final, business-aware decisions. The gateway should reject obviously bad traffic, enforce shared authentication and throttling policy where appropriate, and give central visibility. The endpoint should enforce object access, role or scope checks, tenant separation, and any request-specific exceptions that depend on application state.
CIS Controls v8 supports this split because access control, account management, logging, and configuration safeguards all need to work together rather than rely on one choke point. In practice, that means validating the request at the edge and again where the data or function is actually executed.
NIST SP 800-53 Rev 5 Security and Privacy Controls also reinforces the need for layered control design through access control, identification and authentication, audit, and system integrity controls. The most resilient implementation assumes the gateway can fail open, be bypassed, or be limited by design, so the service remains responsible for the final allow or deny decision.
Risk and Threat Considerations
Relying on the gateway alone creates a single control illusion: it looks centralised, but it does not guarantee that every resource and action is checked correctly where it matters. Attackers look for this gap because a request that passes the gateway can still reach a vulnerable endpoint that fails to revalidate object ownership, scope, or function-level permission.
Failure mechanism: The gateway authenticates or screens the request, then the endpoint trusts that upstream decision and skips its own authorization check, allowing object-level or scope-based abuse when the request reaches the service.
Impact: Sensitive records, privileged actions, or cross-tenant data can be exposed even though the perimeter appears enforced, and detection is often harder because the request may look legitimate by the time it reaches the application.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Directly addresses endpoint-side object authorization failures in APIs. |
| Recommendation — Enforce object-level authorization in every endpoint before returning data. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | API callers and service identities need authenticated trust before authorization. |
| AC-6 — Least Privilege | Gateway-only trust can overexpose API actions unless endpoints limit privilege. | |
| Recommendation — Authenticate API callers and services before evaluating access decisions. Restrict each endpoint to the minimum privileges needed for its function. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The question is fundamentally about where access decisions should be enforced. |
| Recommendation — Apply access control at the service layer, not only at the gateway. | ||
Practitioner Guidance
What to verify: Confirm that every sensitive endpoint independently evaluates caller identity, object ownership, tenant boundary, and action scope. A gateway policy that cannot be enforced again in the service should be treated as an outer filter, not as the security decision.
Decision rule: If the control determines access to a specific record, balance, workflow, or tenant resource, enforce it at the endpoint even if the gateway already checks authentication. Use the gateway to reduce noise and standardise policy, not to replace service-side authorization.
Common mistake: Teams often test the gateway thoroughly and assume the API is secure because traffic is blocked at the edge. The safer assumption is that any endpoint reachable through a valid path must defend itself against direct, replayed, or mis-scoped requests.
Practitioner takeaway: Treat the gateway as a control point that improves consistency and visibility, but treat the endpoint as the final authority for authorization, because that is where object-specific and business-context decisions can be enforced correctly.
Related resources from NHI Mgmt Group
- When should teams prioritise an API gateway over managing monetization controls directly in applications?
- Should API gateway controls replace application-level authorization checks?
- How do security teams decide whether to prioritise gateway controls or edge filtering first?
- How should security teams evaluate an AI gateway when both request-time controls and release-quality checks matter?