The function becomes reachable through a public HTTP endpoint, which increases the chance of unwanted invocation, abuse, or accidental exposure. Teams then have to manage endpoint authentication, request signing, and access policies carefully, especially when the function touches data or operational logic. A secure design assumes the trigger is part of the attack surface, not just the code.
Why exposing Lambda through API Gateway changes the security boundary
api gateway turns the Lambda trigger into a network-facing entry point, so the function is no longer protected only by who can call it inside the cloud account. The real question becomes whether the gateway enforces strong authentication, authorisation, and request validation before execution. Without that, the function is effectively reachable by any party that can discover or guess the endpoint.
That matters because Lambda often sits behind automation, data access, or business logic. If the gateway is too permissive, the exposure is not just “public access”, it is public access to a capability that may read data, trigger workflows, or call other services. Strong design treats the gateway as part of the trust boundary, not as a thin routing layer.
An API exposed this way should be evaluated like any other externally reachable API surface, including token validation, method restrictions, and whether the invocation path can be abused even when the code itself is correct. The presence of a serverless runtime does not reduce the need for access control; it only changes where the control must be enforced.
What fails when authorisation is weak or missing
The most common failure mode is that the function becomes callable by unauthorised users, automated scanners, or downstream systems that were never meant to reach it. In practice, that can lead to unwanted invocation, cost amplification, data exposure, or business logic abuse. If the endpoint accepts requests without a strong identity check, the control plane has become an attack surface.
When a function supports sensitive operations, weak authorisation also creates a path for privilege confusion. A caller may be allowed to reach the gateway but not the underlying action, especially if method-level controls, resource policies, or audience checks are incomplete. For AWS Lambda fronted by API Gateway, the key risk is not only “who can connect”, but “who can cause this specific action to run.”
OWASP API Security Top 10 is directly relevant here because broken authorisation and unrestricted resource use are classic API exposure problems, and the endpoint should be tested as an API, not as a hidden implementation detail.
How practitioners should secure the invocation path
Start by making invocation explicit and bounded. Use a strong authorisation mechanism on the gateway, validate tokens and audiences, and ensure the Lambda resource policy only trusts the intended caller path. If the function is internal by design, do not rely on obscurity or a “hard to find” URL. The control should decide whether the request may invoke the function, not just whether the request reaches the gateway.
Then align the access model with the function’s real blast radius. If the Lambda can touch production data or trigger operational actions, it should have tightly scoped permissions and a narrow invocation policy. This is where least privilege becomes operational, because the gateway, the caller identity, and the function role all need to agree on what is allowed.
For machine-to-machine access, treat authentication and authorisation as separate problems. A valid client credential does not automatically justify every action, and a signed request does not automatically make the caller safe for every route. NHI Authentication Guide, Authorisation Models Guide, and API Key Management Guide are useful references when the gateway depends on client secrets, scopes, or policy-based access decisions.
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 surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Exposed Lambda endpoints fail when routes can invoke actions without proper permission checks. |
| API2 — Broken Authentication | API Gateway exposure depends on whether callers are authenticated before access is granted. | |
| Recommendation — Enforce function-level authorization on every API route before invoking Lambda. Require strong authentication and reject unauthenticated requests at the gateway. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service to Service) | Lambda and API Gateway commonly rely on service authentication for machine-to-machine access. |
| AC-6 — Least Privilege | The function role and caller permissions must be constrained to the minimum allowed action. | |
| Recommendation — Authenticate service callers with managed machine credentials or signed assertions. Restrict invocation and backend permissions to the minimum required scope. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The exposure is fundamentally an access-control problem for an internet-reachable function. |
| Recommendation — Define and enforce access rules for every public API path and backend function. | ||
Practitioner Guidance
What to prioritise: Check whether the gateway is actually enforcing identity-based access control before any Lambda execution path is reachable. If the endpoint is public but the function is sensitive, move the control point to the gateway and verify the function itself does not accept unauthorised direct invocation through alternate paths.
What to verify: Confirm that the endpoint has authenticated callers, method restrictions, and audience or scope checks that match the intended use case. Also verify the Lambda resource policy and execution role so a weak gateway policy cannot be offset by an overly broad backend permission set.
Decision rule: If the function performs data access, state change, or operational automation, treat “publicly reachable” as a high-risk condition unless the request is strongly authenticated and tightly authorised. If the function is genuinely public, limit it to safe, read-only, or heavily rate-limited behaviour.
Practitioner takeaway: The security question is not whether API Gateway can front Lambda, it is whether the full invocation path enforces the same trust standard as the action the function can perform.
Related resources from NHI Mgmt Group
- What happens when an API is exposed to third party integrations without strong controls?
- What happens when function calling is enabled without strong authorization controls?
- What happens when API requests are exposed without gateway controls, quotas, and parameter validation?
- What happens when a developer or API control plane is exposed without strong token and session controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
