IDOR / BOLA: 권한 검증이 빠졌을 때

IDOR(Insecure Direct Object Reference)와 BOLA(Broken Object Level Authorization)는 사실상 같은 문제를 가리킨다. "로그인은 확인하지만, 그 리소스가 요청자 본인 것인지는 확인하지 않는" 패턴이다. OWASP API Security Top 10에서 1위를 차지할 만큼 실무에서 압도적으로 자주 나온다.

원리

GET /api/orders/1042

이 요청이 "로그인 여부"만 확인하고 "1042번 주문이 로그인한 사용자의 것인지"는 확인하지 않으면, 숫자만 바꿔서 (1041, 1043...) 다른 사용자의 주문 정보를 그대로 볼 수 있다. UUID를 쓴다고 완전히 안전한 것도 아니다 — UUID가 응답 어딘가(목록 API, 알림 등)에 노출되면 그걸 수집해서 순회할 수 있다.

파일 다운로드, 계정 정보 수정, 주문 취소처럼 "ID로 특정 리소스를 지정하는" 모든 엔드포인트가 대상이다.

탐지 방법

1. 계정 두 개(A, B)를 만든다.
2. 계정 A로 로그인해서 리소스를 하나 만들고, 그 리소스의 ID/식별자를 확인한다.
3. 계정 B의 세션으로 그 ID를 직접 요청해본다 (URL 파라미터, 요청 바디 모두 시도).
4. GET(조회)뿐 아니라 PUT/PATCH/DELETE(수정/삭제)도 반드시 같이 테스트한다 — 조회는 막혀 있어도 수정은 뚫려 있는 경우가 흔하다.
5. ID가 순차적 숫자면 자동화 스캔(Burp Intruder)으로 넓은 범위를 빠르게 확인할 수 있다.

방어

• 모든 리소스 접근 로직에서 **"인증됨" ≠ "권한 있음"**을 분리해서 매번 확인한다. 쿼리 자체에 소유자 조건을 건다.

-- 이렇게 하지 말고
SELECT * FROM orders WHERE id = ?

-- 이렇게
SELECT * FROM orders WHERE id = ? AND user_id = ?

• 프레임워크 레벨에서 공통 권한 검증 미들웨어를 두고, 예외 없이 모든 리소스 라우트에 적용한다 (라우트 하나 빼먹는 순간 취약점이 된다).
• 순차 ID 대신 예측 불가능한 식별자(UUID)를 쓰는 건 방어 심화 수단이지 근본 해결책은 아니다 — 권한 검증 자체가 반드시 있어야 한다.
• 공유 링크처럼 "링크를 아는 사람 누구나" 접근을 의도한 기능은 예외이므로, 의도된 것과 실수로 빠뜨린 것을 설계 단계에서 명확히 구분해둔다.