Trailing‑Slash Bypass in AWS HTTP API Reveals Authorizer Mismatch

What’s new

Security researcher Piyush Gupta published a proof‑of‑concept that shows a simple trailing slash can bypass the Lambda authorizer on AWS HTTP API, the newer and cheaper variant of API Gateway. A request to GET /v1/accounts returns 401 Unauthorized as expected, but the same request with a trailing slash – GET /v1/accounts/ – returns 200 OK and exposes the full account payload. The same pattern works on POST /v1/transfers/, letting an attacker initiate a wire transfer without a valid JWT.

The root cause is a path‑normalization mismatch:

• The routing layer treats the path as a greedy prefix, so /v1/accounts/ matches the defined route /v1/accounts.
• The authorizer layer evaluates the raw request path, which includes the trailing slash, and therefore does not find a matching authorizer rule. It consequently skips the authorizer, allowing the integration Lambda to run.

AWS documentation for HTTP API mentions greedy matching, but it does not clarify that the authorizer runs on the original path. This gap creates an authentication bypass that can be reproduced with a single extra character.

Developer experience

Reproducing the issue

1. Create an HTTP API with a Lambda authorizer that checks a JWT and writes event.requestContext.authorizer.userId.
2. Define a route GET /v1/accounts linked to a backend Lambda.
3. Invoke the endpoint without a trailing slash – you receive a 401 response.
4. Invoke the same endpoint with a trailing slash – you receive a 200 response and the authorizer field is missing in the event object.

The missing userId is the signal that the authorizer was bypassed. The backend Lambda, if it trusts the presence of userId without further validation, may fall back to a privileged default and return all data.

Why it hurts developers

• Hidden configuration – The mismatch lives inside the managed service, not in user‑controlled code, so static analysis tools cannot flag it.
• Cost‑driven choices – Many teams adopt HTTP API for its lower price and simpler setup, unaware that it sacrifices strict path matching.
• Assumed trust – Relying solely on the authorizer to populate security‑critical fields is a common pattern; the bypass breaks that assumption.

Mitigation steps

1. Audit routes – Run a quick script (e.g., using ffuf or curl) that hits each protected endpoint with and without a trailing slash. Verify that responses and authorizer context are identical.
2. Validate in the integration – Check that required fields such as event.requestContext.authorizer.userId are present and meet your security policy before processing the request.
3. Consider REST API – AWS REST API enforces stricter path matching and does not exhibit this behavior. Switching eliminates the specific bug at the cost of higher latency and price.
4. Add a custom middleware – If you stay on HTTP API, insert a Lambda layer that normalizes the incoming path (e.g., removes trailing slashes) before the authorizer runs, or explicitly reject requests that contain a trailing slash.
5. Monitor AWS announcements – The issue surfaced in a 2024 re:Post thread and was patched locally in the Chalice framework in 2018. Keep an eye on the AWS API Gateway documentation for any future fixes.

User impact

From an end‑user perspective, the bypass can expose sensitive data or allow privileged actions without proper authentication. In the reported fintech case, an attacker could retrieve all customer accounts and initiate transfers, potentially resulting in monetary loss and regulatory breach.

Even if the immediate financial impact is limited, the incident erodes confidence in the API surface. Users expect that a missing or malformed JWT will always be rejected; a silent path‑normalization bug violates that expectation and can lead to data leakage, compliance violations, and brand damage.

Broader context

The pattern mirrors a vulnerability disclosed earlier in 2026 for gRPC‑Go (CVE‑2026‑33186), where the server accepted a non‑canonical :path header, causing authorization interceptors to miss the request. Both cases illustrate that canonicalizing request paths before any security decision is a fundamental defensive measure.

AWS has not publicly acknowledged a fix for the HTTP API bug as of this writing. The community response on Hacker News split between viewing it as a misconfiguration and labeling it a design flaw. Regardless of the classification, teams must treat the mismatch as a security defect and apply the mitigations above.

---

Steef‑Jan Wiggers is a senior cloud editor at InfoQ and a domain architect at VGZ. He focuses on integration platforms, Azure DevOps, and AI‑enabled cloud solutions.