BOLA는 요청에 담긴 ID 값 하나만 바꿔 남의 데이터를 그대로 꺼내는 공격으로, 전체 API 취약점의 40% 이상을 차지하는 1순위 위협이다.
이름이 낯설 뿐, 웹에서 오래 악명 높던 IDOR가 API로 옮겨온 것이다. OWASP API Security Top 10에서도 부동의 1위(API1)로 꼽힌다.
어떻게 뚫리나
쇼핑몰이 /api/orders/1001로 내 주문을 보여준다고 하자. 공격자는 로그인한 상태에서 주소의 1001을 1002로 바꿔 요청한다. 서버가 "이 주문이 정말 이 사용자의 것인가"를 확인하지 않으면 남의 주문·연락처·결제 내역이 그대로 돌아온다. ID가 순차 정수라면 스크립트로 1번부터 끝까지 전체를 열거하는 것도 가능하다.
인증은 됐는데 왜 뚫리나
로그인(인증)은 "네가 누구인지"만 확인한다. BOLA는 "이 리소스가 네 것인지"를 확인하는 인가(authorization)가 빠져서 생긴다. 둘은 완전히 별개다. AI 코딩 도구로 만든 API에서 특히 자주 나타나는데, 생성형 도구는 "데이터를 반환하는" 기능은 잘 짜지만 "요청자가 그 데이터의 주인인지" 확인하는 코드는 좀처럼 붙이지 않기 때문이다.
왜 남 일이 아닌가
API 사고는 이제 전체 데이터 유출의 30%를 넘어섰고, 그 가운데 BOLA가 40% 이상을 차지한다. 화면에는 안 보여도 브라우저 개발자도구나 간단한 스크립트만 있으면 누구나 시도할 수 있어 공격 난이도는 낮고 피해 규모는 크다. 대량 할당(Mass Assignment)이나 GraphQL 스키마 노출과 결합되면 권한 상승까지 이어진다.
자가 점검 4가지
- ID를 바꿔보라 — 로그인한 채로 요청의
id·user_id·주문번호를 옆 번호로 바꿔 남의 데이터가 나오면 취약하다. - 모든 접근에 소유권 조건이 있나 — 조회뿐 아니라 수정·삭제 쿼리까지
where user_id = 현재_세션_사용자같은 소유권 검증이 걸려 있어야 한다. - 추측하기 어려운 식별자 — 순차 정수 대신 UUID를 쓰면 열거를 늦춘다. 다만 이는 보조 수단이고, 근본 해법은 서버의 인가 검증이다.
- 함수 수준 권한도 확인 — 관리자 전용 엔드포인트를 일반 사용자 토큰으로 호출하지 못하게 막았는지 함께 점검한다. 토큰(JWT) 검증과 OAuth 설정도 같은 맥락이다.
공격 표면부터 무료로 점검하세요
자동 스캐너는 외부에 열린 API 경로와 인증 없이 응답하는 엔드포인트 같은 "위험 신호"를 빠르게 찾아줍니다. 다만 "이 토큰으로 실제로 남의 데이터가 열리는지"는 로그인 상태에서 공격 시나리오를 짜야 드러나므로, 자동 점검으로 표면을 좁힌 뒤 사람이 검증하는 것이 정확합니다. 보안 전문 기업 SENTRIX가 실제 모의해킹 기준으로 만든 CodeScan 무료 진단에서 30초 만에 내 사이트 공격 표면부터 확인해 보세요.