객체 수준 권한 검증 실패

객체 수준 권한 검증 실패 (API1: Broken Object Level Authorization, BOLA)

OWASP API 보안 위험 순위에서 꾸준히 1위 자리를 차지하는 리스크가 바로 객체 수준 권한 검증 실패(BOLA)예요. 한마디로 말하면, API가 요청에 실린 객체 ID만 믿고 그 객체를 요청한 사용자에게 진짜 열람 권한이 있는지는 따지지 않는 상황을 뜻해요. 서버가 클라이언트 상태를 온전히 기억하지 못하고 객체 ID 같은 파라미터에 의존하는 API 기반 서비스에서 특히 자주 나타나요. 그래서 공격자는 순차 정수, UUID, 일반 문자열 어느 것이든 객체 ID만 조작하면 남의 데이터에 접근할 수 있게 돼요.

출처: OWASP API Security Top 10 — API1:2023 Broken Object Level Authorization

어떤 API가 취약한가요?

객체 수준 권한 검증은 코드 수준에서 "이 로그인 사용자가 이 객체에 대해 요청한 동작을 수행할 권한이 있는가"를 확인하는 접근 제어 메커니즘이에요. 객체 ID를 받아 그 객체에 어떤 동작을 수행하는 모든 API 엔드포인트는 반드시 이 검증을 넣어야 해요. 여기서 무너지면 정보 노출뿐 아니라 데이터 변조·파괴로 이어질 수 있고, 상황에 따라서는 계정 전체를 탈취당할 수도 있어요.

여기서 오해하기 쉬운 지점을 하나 짚어둘게요. 세션의 사용자 ID를 추출해(JWT 토큰에서 꺼내는 식으로) 취약한 ID 파라미터와 단순히 비교하는 방식만으로는 BOLA를 해결할 수 없어요. 그 접근은 아주 일부 사례만 막을 뿐이에요.

또 하나 분명히 해둘 게 있어요. BOLA에서는 사용자가 해당 엔드포인트에 접근할 권한이 있는 경우가 일반적이에요. 위반이 일어나는 지점은 객체 수준, 즉 ID를 조작하는 데 있죠. 반대로 사용자가 애초에 접근하면 안 되는 엔드포인트나 함수 자체에 접근한 거라면 그건 BOLA가 아니라 깨진 함수 수준 권한 검증(BFLA)으로 봐야 해요.

공격 시나리오

시나리오 #1

전자상거래 플랫폼이 매장별 매출 차트 페이지를 제공한다고 해볼게요. 브라우저 요청을 들여다보면 그 차트의 데이터 소스가 되는 API 엔드포인트와 URL 패턴을 확인할 수 있어요. 예를 들어 /shops/{shopName}/revenue_data.json 같은 형태요. 공격자는 다른 API 엔드포인트로 호스팅된 모든 매장 이름 목록을 얻은 다음, 간단한 스크립트로 {shopName} 자리를 하나씩 바꿔가며 요청을 보내요. 그렇게 수천 개 매장의 매출 데이터에 접근하게 돼요.

시나리오 #2

차량 정보를 노출하는 API가 VIN(차대번호)이 로그인한 사용자 본인 소유의 차량을 가리키는지 검증하지 않는다면 BOLA 취약점이 생겨요. 공격자는 자기 소유가 아닌 차량의 정보를 조회할 수 있게 되죠.

예방 방법

  • 브로커가 아닌 권한 판단의 기준을 사용자에게서 오는 객체 ID가 아니라 현재 세션의 사용자 ID로 두는 게 안전해요.
  • 순차 정수처럼 예측 가능한 객체 ID 대신 추측하기 어려운 불규칙한 ID(UUID 등) 를 사용해요.
  • 모든 객체 접근 지점에서 사용자 소유 여부를 확인하고, ID를 단순 비교하는 대신 관계(relation) 기반으로 접근 권한을 검증해요.
  • 객체 ID 탐색·예측 공격(IDOR)까지 고려해 방어를 설계해요.

더 알아보기