
GET /api/orders/100231 요청 두 개가 있습니다. 하나는 주인이 자기 주문을 연 것이고, 하나는 다른 사람이 번호를 바꿔 넣은 것입니다. 헤더도, 경로 모양도, 응답 시간도 같습니다. 둘을 가르는 정보는 "주문 100231의 주인이 누구인가" 하나뿐이고, 그 답은 DB에만 있습니다. 탐지를 설계하기 전에 공격마다 어느 층에서 보이는지부터 정리해야 하는 이유입니다.
층 네 개
요청은 대략 이렇게 지나갑니다.
- 네트워크(L3·L4). IP, 포트, 연결 수. 방화벽과 DDoS 방어가 봅니다.
- 엣지(L7 앞단). CDN, WAF, API 게이트웨이, 리버스 프록시(Nginx·Envoy). HTTP 메서드·경로·헤더·쿼리·본문을 봅니다.
- 앱. 로그인한 사용자가 누구인지, 그 사용자가 이 객체를 볼 수 있는지, 입력이 스키마에 맞는지 압니다.
- 데이터·업무. 주문의 주인, 계정의 정상 행동, 업무 흐름의 순서를 압니다.
아래로 갈수록 반응은 느려지지만 아는 것이 많아집니다.
다섯 가지 공격
용어부터 맞춥니다.
- IDOR(Insecure Direct Object Reference). 요청에 든 객체 번호만 바꿔 남의 데이터에 닿는 결함입니다. OWASP API Security Top 10 2023에서는 BOLA(API1, Broken Object Level Authorization)라고 부르고 1위에 둡니다.
- 열거(enumeration). 번호, 아이디, 쿠폰 코드를 차례로 대입해 존재하는 것을 찾는 행동입니다. IDOR을 찾는 가장 흔한 방법이기도 합니다.
- 퍼징(fuzzing). 파라미터 이름이나 값을 바꿔 가며 앱이 이상하게 반응하는 곳을 찾는 행동입니다. OWASP 자동화 위협 목록의 OAT-014 취약점 스캐닝에 "크롤링하고 퍼징해서 약점을 찾는다"고 나옵니다.
- 로그인 공격. 유출된 아이디·비밀번호 쌍을 대량으로 넣어 보는 크리덴셜 스터핑(OAT-008), 한 계정에 비밀번호를 바꿔 넣는 크리덴셜 크래킹(OAT-007)이 있습니다.
- 봇·수집. 정상 기능을 사람보다 훨씬 빠르게, 많이 쓰는 행동입니다. 상품 목록을 통째로 긁는 스크래핑(OAT-011)이 대표입니다. API 목록에서는 API4(무제한 자원 소비)와 API6(민감한 업무 흐름의 무제한 접근)에 걸칩니다.
어느 층에서 보이나

| 공격 | 엣지(WAF·게이트웨이)가 보는 것 | 앱만 아는 것 |
|---|
| IDOR | 경로 숫자가 바뀐다는 것, 404 비율 | 이 사용자가 이 객체의 주인인가 |
| 열거 | 같은 경로 모양의 빠른 반복 | 거부된 서로 다른 객체 수, 미끼 객체 접근 |
| 퍼징 | 이상한 문자열(주입 패턴), 처음 보는 파라미터 | 스키마 검증 실패(400·422) 횟수 |
| 로그인 공격 | IP당 로그인 요청 수 | 계정당 실패, 유출 비밀번호 여부, 성공 후 이상 행동 |
| 봇·수집 | 요청 속도, 클라이언트 지문, 봇 점수 | 계정당 조회량, 업무 흐름을 건너뛰는 순서 |
표에서 두 가지가 보입니다.
첫째, IDOR은 앱 안에서만 보입니다. WAF가 아무리 똑똑해도 주문 100231의 주인을 모릅니다. WAF는 "숫자가 빠르게 바뀐다"까지만 압니다. 그래서 천천히 번호를 바꾸는 공격자나, 계정을 여러 개 쓰는 공격자는 엣지에서 정상과 구별되지 않습니다.
둘째, 엣지가 잘하는 일도 분명합니다. 주입 문자열처럼 요청 하나만 봐도 이상한 것, 그리고 IP나 클라이언트 단위의 양입니다. OWASP CRS 같은 규칙 묶음이 겨냥하는 곳이 여기입니다.
그래서 방어선을 나눕니다. 요청 하나로 판단할 수 있는 것은 엣지에서, 객체의 주인이나 계정의 맥락이 필요한 것은 앱에서, 여러 서버를 엮어야 보이는 것은 파이프라인에서 봅니다.
같은 IDOR이라도 모양이 다르다
열거의 모양에 따라 잘 보이는 신호도 달라집니다. 3부 실험에서 쓰는 공격 네 가지입니다.
- 빠른 열거. 계정 하나, IP 하나로 0.2초마다 번호를 1씩 올립니다. 어떤 규칙에도 잘 걸립니다.
- 느린 열거. 90초에 한 번씩 2시간 동안. "1분에 몇 번" 같은 짧은 윈도우를 피합니다.
- IP를 바꾸는 열거. 계정은 하나인데 요청마다 IP가 다릅니다. IP 기준 규칙을 피합니다.
- 계정을 바꾸는 열거. IP는 하나인데 계정 20개가 4건씩 나눠 봅니다. 계정 기준 규칙을 피합니다.
공격자가 무엇을 바꾸느냐에 따라 무엇을 기준으로 세야 하는지가 바뀝니다. 13편과 14편에서 이 네 가지를 같은 실험실에서 비교합니다.
정상도 공격처럼 생겼다
탐지 설계에서 더 어려운 쪽은 사실 정상 트래픽입니다.
- 주문이 60건인 사용자는 목록을 넘기며 주문을 하나씩 엽니다. 서로 다른 객체를 빠르게 봅니다.
- 모바일 앱은 2초마다 같은 목록을 다시 불러옵니다. 잘못 만든 클라이언트는 0.4초마다 부릅니다.
- 가족이 보낸 주문 링크를 열면 남의 주문 1~2건에 접근합니다.
- 통신사 CGNAT(통신사가 공인 IP 하나를 여러 가입자에게 나눠 주는 방식) 뒤의 사용자 수십 명은 같은 IP를 씁니다.
좋은 탐지 규칙은 공격을 잡는 규칙이 아니라, 공격은 잡고 이런 정상은 잡지 않는 규칙입니다. 그래서 이 시리즈는 탐지율과 오탐률을 언제나 같은 표에 둡니다.
정리
- 공격은 층마다 다르게 보입니다. 엣지는 요청 하나의 이상함과 양을, 앱은 주인과 맥락을 압니다.
- IDOR은 앱 안에서만 확실히 보입니다. 엣지에서는 "번호가 빨리 바뀐다"까지만 압니다.
- 공격자가 바꾸는 것(속도, IP, 계정)에 따라 세는 기준을 골라야 하고, 정상 사용자의 모양을 먼저 알아야 합니다.
출처와 확인 날짜
모든 링크는 2026-10-30에 확인했습니다.
이전 글 해킹 시도는 몇 초 안에 잡을 수 있나: 실시간 탐지·차단 시리즈 소개
다음 글 방어선 0: 탐지보다 먼저, 코드에서 막기
시리즈 전체 목록 해킹 시도를 몇 초 안에 잡는 서버 전체 목록