뒤에 붙인 슬래시 하나로 AWS API Gateway 인증을 우회한 사례

• 보안 연구자 Piyush Gupta가 발견한 내용: AWS API Gateway의 더 새롭고 저렴한 변형인 AWS HTTP API에서 API 경로 끝에 trailing slash를 추가하면 Lambda authorizer 인증을 완전히 우회할 수 있었음

  • GET /v1/accounts는 401 Unauthorized 반환

  • GET /v1/accounts/는 전체 계정 데이터를 담은 200 OK 반환

  • 같은 우회가 POST /v1/transfers/에도 적용돼, 유효한 JWT 없이 wire transfer 시작 가능

• 근본 원인: HTTP API 내부의 두 레이어가 경로를 정규화하는 방식이 서로 달랐음

  • route matching 레이어는 해당 path가 존재하는지 판단

  • authorizer 레이어는 요청 허용 여부 판단

  • 두 레이어가 무엇을 "match"로 볼지 서로 다르게 해석

• Gupta의 설명:

HTTP API는 기본적으로 greedy path matching을 한다. /v1/accounts/는 prefix로 /v1/accounts와 매치됐다. authorizer가 실행돼 Allow를 반환했다. 그다음 integration이 실행됐지만 integration mapping은 느슨했다. 경로가 다시 써졌고 auth context가 떨어져 나가면서, 유효한 JWT 없이도 내부로 들어가게 됐다.

• 이 동작 방식은 HTTP API와 Lambda authorizer를 쓰는 모든 팀이 이해할 가치가 있음

  • authorizer는 인증된 요청에 context.authorizer.userId 설정

  • backend Lambda는 이 필드를 읽어 데이터 접근 범위 결정

  • trailing-slash path가 integration에 도달했을 때 userId는 undefined로 들어왔음

  • backend는 이 필드를 독립적으로 검증하지 않고 authorizer가 설정했을 것이라고 신뢰

  • userId가 undefined가 되자 integration이 system account로 기본 처리돼 모든 데이터 반환

• Gupta는 ffuf로 path를 퍼징해 이 동작을 확인

• 해당 fintech는 다음 날 문제를 수정

  • HTTP API에서 더 엄격한 path matching을 하는 REST API로 전환

  • authorizer만 신뢰하지 않고, 모든 Lambda 함수에서 userId를 직접 검증하도록 추가

• Gupta는 Reddit에서 영향 여부를 각 팀이 직접 검증할 수 있도록 재현 절차도 제시

재현하려면 lambda authorizer가 붙은 HTTP API를 만들고, trailing slash가 있는 경우와 없는 경우로 route를 호출한 뒤 integration lambda에서 event.requestContext.authorizer를 확인하면 된다. slash가 없을 때는 존재하고, slash가 있을 때는 빠져 있다. 그게 drop이다.

• Reddit의 한 댓글은 HTTP API의 개발 방향에 대해 팀들이 고려해야 할 맥락도 덧붙였음

더 새로운 API이긴 하지만 4~5년 전 조용히 개발이 보류됐다. 기본 내부 아키텍처에 문제가 있었고, 기능 투자 중단을 결정한 것 같다는 이야기였다.

• 이 말이 사실이라면, 비용 절감을 위해 HTTP API를 REST API보다 우선 선택하는 팀은 이런 종류의 path-matching 동작에 대한 수정이 실제로 나올 가능성도 함께 따져봐야 함

• 이 취약점은 고립된 사례가 아님

  • 2026년 3월 공개된 CVE-2026-33186도 gRPC-Go에서 거의 동일한 패턴을 드러냈음

  • 서버가 :path pseudo-header에 필수인 leading slash가 빠진 요청을 받아들이고도 올바른 handler로 라우팅했을 때, authorization interceptor는 비정규 경로 원문을 평가하면서 deny rule과 매치하지 못했음

  • 수정 원칙은 authorization 레이어에 도달하기 전에 비정규 path 요청을 거부하는 것, 여기에도 같은 원칙이 적용됨

• AWS API Gateway의 trailing slash 문제 자체는 새롭지 않음

  • 2024년의 AWS re:Post thread에 path-stripping 동작이 기록돼 있음

  • AWS Chalice framework는 2018년에 로컬 개발 모드에서 API Gateway의 trailing-slash 처리와 맞추도록 패치했음

  • 이번에 새로 드러난 점은 path matching과 authorization의 불일치가 단순 라우팅 혼선이 아니라 인증 완전 우회로 악용될 수 있다는 시연

• Hacker News에서는 이를 misconfiguration으로 볼지, 플랫폼 설계 문제로 볼지를 두고 논쟁이 갈렸음

  • 한 댓글은 AWS 책임이 크다고 봤음

사람들이 이런 말을 하는 게 싫다. 내가 AWS API gateway가 이렇게 동작하길 바랄 세상은 없고, 실수로라도 마찬가지다. HTTP에는 이런 footgun이 널려 있고, slash 유무 차이는 고전적인 사례다. 좋은 소프트웨어라면 이런 실수를 하기 어렵게 만들어야 하고, 아마 trailing slash 유무와 관계없이 같은 동작을 기본값으로 해야 한다.

• 다른 댓글은 이 패턴이 AWS보다 훨씬 오래됐다고 지적

수십 년 전 첫 직장에서 겪었다. 고객사 gateway가 http://foo.com/update.exe를 막아서 내 노트북에서 뭔가 업데이트할 수 없었다. 그런데 http://foo.com/update.exe?는 우회로 통했다.

• AWS HTTP API와 Lambda authorizer를 쓰는 팀의 즉각적인 조치

  • 보호된 route의 trailing-slash 변형이 서로 다른 응답을 반환하는지 점검

  • backend Lambda 함수가 authorizer만 유일한 gatekeeper로 신뢰하지 말고, authorization context 필드를 독립적으로 검증하도록 보장

  • 더 높은 비용과 더 낮은 성능을 감수하더라도, 보안 민감 엔드포인트에는 REST API의 더 엄격한 path matching이 적절한지 검토

^{source https://www.infoq.com/news/2026/06/aws-api-gateway-auth-bypass}