객체수준 권한부여 취약점 (Broken Object Level Authorization (BOLA))

한 줄 정의: API가 요청한 사용자에게 특정 자원(객체)에 접근할 권한이 실제로 있는지를 제대로 검증하지 않아, 다른 사용자의 데이터에 접근할 수 있게 되는 취약점입니다.

쉽게 풀면

온라인 서비스에서 자신의 주문 내역을 볼 때 주소창의 주문번호를 다른 숫자로 바꿔서 입력했더니 남의 주문 정보가 그대로 보이는 상황을 떠올리면 됩니다. 서버는 "로그인이 되어 있는가"만 확인하고, "이 사람이 정말 그 주문번호의 주인인가"는 확인하지 않은 것입니다. 객체수준 권한부여 취약점은 바로 이렇게, 인증(누구인지 확인)은 되어 있지만 인가(그 자원에 접근할 자격이 있는지 확인)가 빠져서 생기는 문제입니다. 겉으로는 로그인 기능이 멀쩡해 보여도 실제로는 남의 정보를 아주 쉽게 들여다볼 수 있는 상태인 셈입니다.

왜 중요한가

이 취약점은 API를 통해 개인정보나 민감한 데이터를 다루는 서비스에서 흔히 발견되며, 주요 웹 API 보안 취약점 목록에서도 꾸준히 상위권으로 다뤄질 만큼 실무에서 자주 나타납니다. 단순히 객체 식별자를 순차적으로 바꿔보는 것만으로도 대량의 데이터가 유출될 수 있어 웹 애플리케이션 보안 분야의 중요한 연구 및 점검 대상입니다.

논문에서는 이렇게 쓰입니다

"조사 대상 API의 상당수에서 사용자 식별자를 임의로 변경했을 때 타인의 자원 정보가 노출되는 객체수준 권한부여 취약점이 발견되었다."

요청 값 하나만 바꿔서 다른 사용자의 데이터를 확인할 수 있었던 실태를 조사한 연구라는 뜻입니다.

"자원 접근 시마다 소유권을 검증하는 서버 측 권한 검사 로직의 부재가 주요 원인으로 지적되었다."

API가 요청을 처리하기 전에 그 요청자가 실제 소유자인지 매번 확인하는 절차가 빠져 있었던 것이 근본 원인이라는 설명입니다.

조금 더 깊게 보면

이 취약점은 REST API에서 객체 식별자(ID)를 URL이나 요청 본문에 직접 노출하는 설계와 결합될 때 특히 자주 나타나며, 자동화 도구로 ID 값을 순차 대입해 탐색하는 방식으로 쉽게 발견되기도 합니다. 방어를 위해서는 매 요청마다 서버 측에서 요청자와 대상 자원의 소유 관계를 검증하는 절차가 필요하며, 예측하기 어려운 식별자(UUID 등)를 사용하는 것도 보조적인 완화책으로 언급됩니다.

주의할 점

식별자를 추측하기 어렵게 만드는 것만으로는 근본적인 해결책이 되지 않으며, 반드시 서버 측에서 접근 권한 자체를 검증하는 로직이 함께 있어야 합니다.