A Trailing Slash Bypassed AWS API Gateway Authorization - InfoQ

BT

InfoQ Software Architects' Newsletter

A monthly overview of things you need to know as an architect or aspiring architect.

View an example

Enter your e-mail address

Select your country

Select a country

I consent to InfoQ.com handling my data as explained in this Privacy Notice.

We protect your privacy.

Close

Helpful links

About InfoQ

InfoQ Editors

Write for InfoQ

About C4Media

Diversity

Choose your language

En

中文

日本

Fr

Aug26,2026

AI Security & Privacy Engineering Certification

Secure and govern production AI systems, from sensitive data to guardrails, evals, and audits.<br>Online. Register now.

Sep14,2026

Architect Certification

Distributed systems, decentralized decisions, platform engineering, and AI architecture.<br>Online. Register Now.

Aug21,2026

Engineering Leadership Certification

Work through leadership decisions with senior peers facing similar technical trade-offs.<br>Online. Register Now.

Nov16-20,2026

QCon San Francisco

What's working across AI, architecture, and leadership, from the teams doing it.<br>Register. Early bird ends August 11.

Dec15-16,2026

QCon AI New York

Production AI across agents, context, evals, security, and infrastructure, from the senior engineers building it.<br>Registration open.

Apr13-16,2027

QCon London

What early-adopter teams have proven in production, across 15 engineering tracks.<br>Register. Early bird ends August 11.

InfoQ Homepage

News

A Trailing Slash Bypassed AWS API Gateway Authorization

Cloud

A Trailing Slash Bypassed AWS API Gateway Authorization

Jun 01, 2026

min read

by

Steef-Jan Wiggers

Follow us on

Youtube232K Followers

Linkedin26K Followers

InstagramNew

RSS19K Readers

X57.1k Followers

Facebook21K Likes

BlueskyNew

Listen to this article - 0:00

Audio ready to play

Your browser does not support the audio element.

0:00

0:00

Normal1.25x1.5x

Like

Reading list

Security researcher Piyush Gupta discovered that adding a trailing slash to API paths on AWS HTTP API, the newer and cheaper variant of API Gateway, could bypass Lambda authorizer authentication entirely. GET /v1/accounts returned 401 Unauthorized. GET /v1/accounts/ returned 200 OK with full account data. The same bypass worked on POST /v1/transfers/, allowing Gupta to initiate a wire transfer without a valid JWT.

The root cause is a path normalization mismatch between two layers of HTTP API that make independent decisions. The route matching layer determines whether a path exists. The authorizer layer determines whether the request is allowed. Those two layers disagreed on what constitutes a "match."

Gupta explains:

HTTP API does greedy path matching by default. /v1/accounts/ matched /v1/accounts as a prefix. The authorizer ran and returned Allow. Then the integration executed, but the integration mapping was fuzzy. The path got rewritten, the auth context got dropped, and suddenly I was inside without a valid JWT.

The mechanics are worth understanding for any team using HTTP API with Lambda authorizers. The authorizer sets context.authorizer.userId on the authenticated request. The backend Lambda reads that field to scope data access. When the trailing-slash path hit the integration, userId arrived as undefined. The backend didn't validate the field independently, it trusted the authorizer to have set it. With userId undefined, the integration defaulted to a system account, returning all data.

Gupta confirmed the behavior by fuzzing paths with ffuf:

The fintech fixed the issue the next day by switching from HTTP API to REST API (which has stricter path matching) and adding userId validation in every Lambda function rather than relying solely on the authorizer. On Reddit, Gupta provided reproduction steps for any team to verify whether their own APIs are affected:

If you want to reproduce, create an HTTP API with a lambda authorizer, hit the route with and without trailing slash, and check event.requestContext.authorizer in the integration lambda. It'll be present without slash, missing with slash. That's the drop.

One Reddit commenter added context about HTTP API's development trajectory that teams should factor in:

It is the newer API but development was quietly put on hold 4-5 years ago. Something about the basic internal architecture having problems and they decided to stop investing in features.

If accurate, teams choosing HTTP API over REST API for cost savings should weigh whether the product is likely to receive fixes for this class of path-matching behavior.

This is not an isolated class of vulnerability. In March 2026, CVE-2026-33186 disclosed a nearly identical pattern in gRPC-Go, when the server accepted requests where the :path pseudo-header omitted the mandatory leading slash, and successfully routed them to the correct handler, authorization interceptors evaluated the raw non-canonical path and failed to match deny rules. The fix was to reject any request with a...