이 상혁BOLA(Broken Object Level Authorization)란
객체 수준 인가 실패를 말하며, OWASP의 공식 API Security Top 10에서 BOLA는 API1:2023 으로 가장 높은 취약점으로 분류 되어 있습니다.
최근 금융권 침해사고의 경우 외부 비인가자가 정상적인 본인확인 절차를 거치지 않고 조회 서비스에 접근했으며, 조회 입력값을 바꿔 정보를 호출하고 확보한 고객번호를 이용해 다른 정보에 접근한 것으로 알려져 있습니다.
본인확인 우회는 인증 실패에 가까우나, 고객 식별값을 이용한 타인 정보 접근이 객체별 권한 검사 누락으로 발생했을 경우 BOLA에 해당합니다.
BOLA는 AI가 등장하면서 새롭게 생긴 취약점이 아닙니다. 과거에도 존재했던 API의 객체별 접근권한 검증 오류입니다.
달라진 점은 공격 방식의 자동화 수준입니다.
기존에는 공격자가 직접 웹페이지와 JavaScript를 분석하고, API 주소와 파라미터를 식별한 뒤, 요청과 응답을 비교해 취약점 존재 여부를 판단했습니다.
반복 요청은 스크립트로 자동화할 수 있었지만, 어떤 API를 조사할지와 실패 후 어떤 방법을 시도할지는 주로 사람이 결정했습니다.
반면 ARTEX 같은 AI Agent 기반 도구는 웹사이트 구조와 API를 분석하고, 테스트 계획을 생성하고, 실행 결과에 따라 다음 검증 작업을 선택하는 과정을 자동화할 수 있습니다.
예를 들어, 특정 API가 고객번호를 이용해 데이터를 조회한다는 사실을 발견하면 다른 권한의 테스트 계정과 객체를 비교하여 접근통제가 정상적으로 작동하는지 검증할 수 있습니다.
BOLA는 API가 특정 데이터 객체에 접근할 때 요청자가 해당 객체에 대한 권한을 갖고 있는지 제대로 확인하지 않는 취약점입니다.
Object(객체)는 서버가 관리하는 하나의 데이터 단위입니다.
예를 들어 금융서비스에서는 고객정보, 계좌, 대출 신청서, 거래내역, 계약서 등이 모두 객체가 될 수 있습니다
|
구분 |
Authentication(인증) |
Authorization(인가) |
|
의미 |
누구인지 확인 |
무엇에 접근할 수 있는지 확인 |
|
질문 |
로그인한 사용자 A가 맞는가? |
A가 고객 B의 대출정보를 볼 수 있는가? |
|
대표 수단 |
세션, JWT, 비밀번호, MFA |
소유권 검사, 담당자 관계, 역할·정책 검사 |
|
실패 시 |
신원 확인 실패 또는 인증 우회 |
권한 없는 데이터 접근 |
BOLA는 주로 두 번째인 인가(Authorization)의 실패입니다.
BOLA가 존재하면 정상 사용자라는 사실만 확인하고, 다른 사용자의 데이터까지 반환할 수 있습니다.
OWASP도 사용자가 API 기능을 이용할 권한은 있지만 특정 객체에 대한 권한이 없을 때 발생하는 문제를 BOLA로 설명합니다.
BOLA의 동작 원리를 이해하기 위해 가상의 금융회사 대출 조회 서비스를 예로 들어보겠습니다.
1. 정상적인 대출 조회 API
금융회사 직원 A가 자신이 담당하는 고객의 대출 신청서를 조회한다고 가정하겠습니다.
GET /demo/api/loans/1001 HTTP/1.1 Host: example.test Authorization: Bearer <USER_A_TOKEN>
|
요소 |
역할 |
|
GET |
서버에 정보 조회 요청 |
|
/demo/api/loans/ |
대출정보 조회 API |
|
1001 |
조회할 대출 신청서의 객체 ID |
|
Authorization |
사용자 A의 인증 정보 |
정상적으로 권한이 있는 자료를 요청할 경우 아래의 응답을 받을 수 있습니다.
{
"loanId": 1001,
"customerName": "고객A",
"status": "심사중"
}
2. 비정상적인 대출 조회 API
BOLA 공격에서 중요한 것은 인증정보를 반드시 위조해야 하는 것이 아니라는 점이며,
이미 정상적으로 인증된 사용자 A가 접근 대상의 객체 ID만 바꿀 수도 있습니다.
GET /demo/api/loans/1002 HTTP/1.1 Host: example.test Authorization: Bearer <USER_A_TOKEN>
이때 1002는 사용자 A에게 조회 권한이 없는 다른 고객의 신청서라고 가정하겠습니다.
정상적인 서버는 다음과 같이 응답해야 합니다.
HTTP/1.1 403 Forbidden or HTTP/1.1 404 Not Found
하지만 BOLA 취약점이 있다면 서버가 아래와 같은 데이터를 반환할 수 있습니다.
HTTP/1.1 200 OK
Content-Type: application/json
{
"loanId": 1002,
"customerName": "고객B",
"status": "승인완료",
"loanAmount": 50000000
}
즉, BOLA는 데이터베이스가 잘못된 정보를 찾는 문제가 아니라, 올바른 데이터를 권한 없는 사람에게 전달하는 문제입니다.
이 때문에 요청 자체가 정상적인 API 요청과 거의 같아 보일 수 있습니다. SQL Injection처럼 특수한 SQL 문자열이 반드시 포함되는 것도 아닙니다.
BOLA를 막기 위해 가장 중요한 방어책은 서버에서 요청 주체, 접근 대상 객체, 수행하려는 작업을 함께 검증하는 것입니다.
1. 잘못된 데이터 조회 방식
다음은 개념적으로 취약한 서버 코드를 단순화한 예시입니다.
def get_loan(user, loan_id):
loan = database.get_loan(loan_id)
return loan
이 코드에서는 사용자 인증정보를 전달받더라도 실제 데이터 접근권한을 확인하지 않습니다.
사용자가 어떤 객체 ID를 요청했는지만 확인하고 해당 데이터를 반환합니다.
2. 올바른 권한 검증 방식
def get_loan(user, loan_id):
# 요청된 대출정보 조회
loan = database.get_loan(loan_id)
if loan is None:
return {"error": "Not Found"}, 404
# 현재 사용자가 이 대출정보를
# 조회할 권한이 있는지 확인
if not authorization.can_read(user, loan):
return {"error": "Forbidden"}, 403
# 허용된 필드만 반환
return {
"loanId": loan.id,
"status": loan.status
}, 200
BOLA의 가장 어려운 점 중 하나는 공격 요청이 정상적인 비즈니스 요청처럼 보일 수 있다는 것입니다.
예를 들어 WAF가 다음을 관찰했다고 가정하겠습니다.
GET /api/loans/1002 Authorization: Bearer <VALID_TOKEN>
일반적인 요청 형태이고 인증 토큰도 유효합니다.
그러나 API 서버의 권한 정책을 확인하면 이 사용자가 해당 자료를 조회해서는 안 되는 상황일 수 있습니다.
따라서 탐지는 단순 공격 문자열 검사보다 업무상 접근 관계와 행위 패턴의 상관분석이 중요합니다.
BOLA의 본질은 간단합니다.
“로그인에 성공했다는 이유만으로 다른 사람의 데이터까지 접근할 수 있어서는 안 된다.”
API는 요청을 처리하기 전에 누가 요청했는지뿐 아니라, 어떤 데이터에 어떤 작업을 하려는지, 그 작업을 수행할 권한이 있는지까지 검증해야 합니다.
또한 WAF, API Gateway, MFA, Rate Limiting 등의 보안 기술은 이러한 검증을 보완하는 수단이지 대체하는 수단이 아닙니다.
보안업체 안랩 2026년 10월 12일 공개자료 BOLA 취약점 대응 가이드
이 글은 본인의 실제 경험과 학습을 기반으로 직접 작성하였으며, AI는 참고용으로만 활용하였습니다.