결제 라우터 우회 취소 직접 호출 7곳 차단
목차
결제 시스템에서 클라이언트가 정상 플로우를 벗어나 취소 API를 직접 호출하려는 취약점을 발견했다. 같은 문제가 여러 진입점에서 반복되고 있었고, 자동 검증 도구의 지적으로 일괄 보강을 진행했다.
라우터 우회의 위험성
결제 시스템에서 "라우터 우회"라는 것은 의외로 흔한 문제다. 클라이언트가 정해진 비즈니스 흐름을 따르지 않고, 특정 API 엔드포인트를 직접 호출하는 것을 뜻한다. 우리 경우엔 웰컴 결제와 관련해 사용자들이 정상적인 취소 프로세스를 거치지 않고 취소 핸들러를 직접 요청하려던 것 같다.
이게 왜 문제일까? 결제 도메인에서 취소는 단순 데이터베이스 업데이트가 아니다. 여러 검증 로직을 거쳐야 한다. 이미 정산된 결제는 취소할 수 없어야 하고, 웰컴 같은 특정 상품 관련 특수한 규칙이 있을 수 있다. 정상 라우터를 거치면 이런 검증이 자동으로 적용되지만, 우회되면 위험한 상태가 될 수 있다. 실제로 비즈니스팀과의 논의 결과 2026년 6월부터 웰컴을 비활성화하기로 결정했고, 그 전까지의 우회 시도를 차단해야 했다.
분산된 엔트리포인트, 같은 문제
문제는 이 취약점이 단 한 곳에만 있지 않았다. 변경 파일 목록에서 보다시피 charge와 payment 웹 레이어에 각각 여러 클래스가 있었고, 거기서 웰컴 취소 직접 호출이 가능한 지점이 총 7곳이었다.
이런 상황은 시스템이 성장하면서 자주 마주치는 패턴이다. 처음엔 한 곳에서만 기능을 구현하고, 시간이 지나며 유사한 기능이 여러 레이어나 모듈에 흩어진다. 복사-붙여넣기로 인한 중복 코드, 각 팀이 독립적으로 구현한 부분들, 점진적 리팩토링 과정에서 놓친 부분들... 보안이나 비즈니스 로직 검증이 필요한 상황이 되면, 이런 분산된 지점들을 모두 찾아내서 일괄 보강해야 한다.
Codex 검증과 팀 협업
우리가 이 문제를 잡아낸 건 우연이 아니었다. jeju Step 2 프로젝트의 보강 과정에서 codex 검증 도구(자동화된 코드 및 로직 검증 시스템인 것 같음)가 지적했다. 자동 검증은 이런 때 정말 유용하다. 사람이 모든 엔트리포인트를 수동으로 추적하기는 어렵지만, 도구는 패턴을 인식해 일관성 없는 부분을 건져낸다.
팀으로선 검증 지적을 받았을 때 선택이 있다:
- 각 위치를 하나씩 수정하고 테스트하기
- 공통 검증 로직으로 중앙화하기
- 임시방편으로 막기
우리는 첫 번째 방식을 택했다. 이유는 jeju Step 2가 이미 진행 중인 프로젝트였고, 중앙화 리팩토링은 별도 작업으로 계획되어 있었기 때문이다. 실수할 여지를 줄이고, 웰컴 비활성화 정책과도 맞춰야 했으니 당장은 각 진입점을 직접 보강하는 게 낫다고 판단했다.
회고와 다음
이 작업에서 배운 점은 몇 가지다.
첫째, 결제 도메인에서 "라우터 우회"는 생각보다 심각하다. 비즈니스 로직이 진입점마다 산재되어 있으면, 한 번의 검증이 모든 경로를 커버하지 못한다. 장기적으로는 결제 취소 같은 핵심 동작을 서비스 레이어로 중앙화하고, 웹 컨트롤러는 라우팅과 인증만 담당하도록 구조를 개선해야 한다.
둘째, 자동 검증 도구의 가치다. 우리가 놓친 부분을 도구가 찾아줬고, 그덕에 일괄 보강이 가능했다. 다만 codex 지적을 받을 때 팀이 충분히 이해하고 우선순위를 정해서 대응해야 한다는 생각도 든다. 단순히 "고쳐야 하니까" 하는 게 아니라, 왜 이게 문제인지, 비즈니스 영향이 뭔지 함께 논의하는 게 중요하다.
셋째, 웰커 비활성화 정책이 함께 나간 건 흥미로운 부분이다. 단순 보안 패치가 아니라, 비즈니스 결정(웰컴 종료)과 함께 진행되었기에 더 완전한 차단이 가능했다. 팀이 기술과 비즈니스를 함께 고려한 셈이다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.