You require authorisation by configuring each method or route to use an authoriser rather than leaving it open. Protect every operation that reads or changes data, and treat public endpoints as exceptions that must be deliberate. After configuration, test direct requests without valid credentials or tokens to confirm they are rejected as intended.
Why API Gateway authorisation has to be set per method or route
Amazon api gateway does not become protected just because the API exists. Authorisation is enforced at the method or route level, so each operation that exposes data or triggers a business action must be explicitly attached to an authoriser. That design matters because one forgotten route can become the easiest path around your intended access policy.
For REST APIs and HTTP APIs alike, the practical question is not whether the gateway supports authorisation, but whether every exposed operation is intentionally covered. If a route is left open, callers can often reach it directly even when adjacent routes are protected, which creates a policy gap rather than a partial control.
When you review an API, think in terms of access surface, not just endpoint count. The API Security Guide is useful here because gateway configuration is only one part of the wider API security picture, and an authorised gateway still needs inventory, testing, and least-privilege design behind it.
How to configure authorisation without leaving accidental gaps
The cleanest pattern is to define a default posture that assumes operations are protected, then make deliberate exceptions only for genuinely public endpoints. That includes health checks, discovery endpoints, or onboarding flows where openness is intentional and documented. The burden is on the owner to prove why a route should be public, not why it should be protected.
Choose the authoriser type that matches the trust model for the API. JWT-based authorisation, Lambda authorisers, and IAM-based controls each solve different problems, but the important point is consistency: the route must evaluate caller identity or token validity before the integration receives the request. If you mix models across routes, keep the reasoning explicit so security review can see where the decision boundary sits.
Authorisation logic also needs to align with the permissions model behind the API. If the gateway is protecting business actions, route-level checks should reflect the same resource and action boundaries that the backend expects. The Authorisation Models Guide is a useful companion when you need to decide whether roles, attributes, relationships, or policy-based decisions best fit a given set of routes.
Operationally, configuration drift is the main failure mode. A new route may be deployed with a default setting that differs from the existing protected paths, or a refactor may recreate a route with weaker settings than the original. Make route protection part of release validation, not a one-time design choice.
How to prove the control is working after deployment
Configuration alone is not enough. After the change, test each protected method or route with requests that omit credentials, present expired tokens, or use tokens that lack the required claims or scopes. The goal is to confirm that the gateway rejects unauthorised access before the request reaches the backend, not merely that the application later denies the action.
It also helps to validate both negative and positive paths. A protected route should fail closed for anonymous or insufficiently privileged callers, while legitimate clients should still succeed with the expected token or identity context. If the same token can reach routes it should not, the issue is usually in route mapping, claims evaluation, or an overly broad policy rather than in the backend service itself.
For teams building broader API programmes, the OWASP API Security Top 10 provides the right external lens because broken authorisation is one of the most common and most damaging API failures, and gateway misconfiguration is a frequent way it appears in practice.
Risk and Threat Considerations
Leaving even one route open can expose data, enable unauthorised writes, or create a path to privileged backend operations that the rest of the API was meant to block. Attackers often look for exactly these inconsistencies, because a single unprotected operation can bypass the controls that secure the rest of the service.
Failure mechanism: A route is deployed without an authoriser, or with a weaker authorisation check than adjacent routes, so the gateway forwards requests that should have been rejected at the edge.
Impact: Exposure can range from data leakage to unauthorised transactions, and in some APIs that gap becomes a direct privilege-escalation path into downstream systems.
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 OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Route-level auth failures directly expose protected API actions. |
| API2 — Broken Authentication | API Gateway authorisers must reject invalid or missing credentials at the edge. | |
| Recommendation — Enforce route authorization checks before invoking sensitive backend functions. Require valid authentication on every protected route and fail closed. | ||
| OWASP ASVS | V8 — Authorization | The question is about enforcing access control on API operations. |
| Recommendation — Map each method or route to an explicit authorization rule and test denial paths. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Gateway routes need policy enforcement before requests reach the backend. |
| IA-2 — Identification and Authentication (Organizational Users) | Protected methods rely on caller identity being established before access is allowed. | |
| Recommendation — Apply access enforcement at the API edge for each protected operation. Authenticate callers before allowing access to protected API methods. | ||
Practitioner Guidance
What to verify: Confirm that every non-public method or route has an explicit authoriser attached and that your deployment pipeline checks for accidental exceptions. A route inventory is only useful if it is tied to an ownership decision and a known auth policy.
Common mistake: Teams secure the most obvious CRUD routes and then forget proxy paths, helper endpoints, or newly added routes. Those secondary paths are where authorisation gaps usually survive review.
Decision rule: If a route can read data, change state, or invoke a sensitive backend function, treat open access as a defect unless there is a documented business reason for it to remain public.
Practitioner takeaway: The control is effective only when route protection is explicit, repeatable, and testable, because the risk is rarely a missing API gateway altogether, it is the one method that was left outside the policy.