BOLA의 "인가 공백"에 런타임 전략이 필요한 이유

업계 동향 | 2026년 2월 13일

OWASP API 보안 10대 취약점 중 하나인 객체 수준 권한 부여 취약점(BOLA)의 경우, 시프트 레프트만으로는 충분하지 않습니다. BOLA는 오타와 같은 단순한 코딩 오류가 아니라 비즈니스 로직의 근본적인 결함입니다.

광범위한 마이크로서비스 환경에서 개발자가 모든 소유권 규칙을 일일이 수동으로 확인하도록 맡기는 것은 위험 부담이 큰 도박입니다. 2026년에는 미국 증권거래위원회(SEC)의 엄격한 공시 규정과 유럽 일반개인정보보호법(GDPR)의 강력한 집행으로 인해 ‘로직 버그’가 순식간에 중대한 재정적 재앙으로 번질 수 있습니다.

인가 격차의 구조

모놀리식 아키텍처 시대에는 권한 부여가 암묵적으로 이루어졌습니다. 서버는 자체 메모리에 세션을 보관하고 누가 로그인했는지 정확히 파악했으며, 하나의 중앙 집중식 프로세스에서 데이터베이스 쿼리를 제어했습니다.

현대의 클라우드 아키텍처는 이러한 모델을 완전히 무너뜨렸습니다. 오늘날에는 외부 공급자가 관리하는 ID와 수백 개의 개별 서비스에 분산된 데이터를 분리합니다. 사용자가 누구인지는 진입 단계에서 확인하지만, 사용자가 무엇을 소유하고 무엇에 접근할 수 있는지에 대한 검증은 백엔드 개발자에게 맡기는 경우가 많습니다.

“2026년에는 BOLA 공격이 데이터 유출로 이어지는 가장 빠른 경로 중 하나입니다. 기술적 버그를 찾는 데는 ‘시프트 레프트’가 효과적이지만, 잘못된 비즈니스 로직을 바로잡는 유일한 방법은 ‘스테이 라이트’입니다.”

‘인가 공백’은 로그인에는 성공했지만 소유권 확인이 누락된 사이의 허점을 의미합니다. 최신 서비스는 상태 비저장 방식이므로 수신한 요청을 본질적으로 신뢰합니다. 요청에 ‘주문 7788’이 포함되어 있는데 코드에서 해당 주문이 요청자의 소유인지 명시적으로 확인하지 않으면 데이터가 탈취됩니다.

인가 공백 시각화

웹 애플리케이션 방화벽(WAF)에만 의존해서는 BOLA 취약점을 충분히 방어할 수 없는 이유를 이해하려면, 최신 무상태 API에서 인증과 리소스 소유권 사이에 존재하는 기술적 단절을 살펴봐야 합니다. WAF는 SQL 인젝션과 같은 ‘잘못된’ 구문을 탐지하지만, BOLA 공격은 정상적인 요청처럼 보이는 ‘올바른’ 구문을 사용합니다. BOLA를 차단하려면 방어 체계가 ID를 인식하고, 사용자가 요청하는 특정 객체에 대한 권한이 있는지 검증해야 합니다.

은행 애플리케이션을 예로 들어 보겠습니다. 공격자인 사용자 A가 자신의 계정(사용자 ID: 8899)에 로그인하여 유효한 세션 토큰을 발급받습니다. 이제 이 사용자는 인증된 상태이며, 공격자는 /api/v1/accounts/1234/balance로 요청을 보내 다른 사람인 사용자 B의 데이터에 액세스를 시도할 수 있습니다.

WAF는 SQL 인젝션이나 악성 스크립트가 있는지 검사합니다. 1234는 완전히 유효한 정수이고 구문에도 문제가 없으므로 WAF는 요청을 통과시킵니다.

API 게이트웨이는 세션 토큰이 유효하고 만료되지 않았는지 확인합니다. 공격자인 사용자 A는 정상적으로 로그인한 합법적인 사용자이므로, 게이트웨이는 해당 요청을 인증된 것으로 표시하고 백엔드의 내부 시스템으로 전달합니다.

그 결과, 백엔드 서비스는 이 “신뢰할 수 있는” 요청을 받아 계정 1234의 잔액을 반환합니다. 공격자는 게이트웨이가 자신의 신원은 확인했지만, 자신이 무엇에 접근할 수 있는지는 전혀 확인하지 않았기 때문에 보안을 우회하는 데 성공했습니다.

‘이전’ 시나리오: 무너진 신뢰 모델

많은 현대적 아키텍처에서 API 게이트웨이는 입구에서 신분증만 확인하는 ‘문지기’ 역할을 합니다. 사용자가 유효한 JWT 또는 세션 쿠키를 제시하면 게이트웨이는 이후 해당 사용자가 보내는 모든 요청이 적법하다고 간주합니다.

사용자 A가 로그인하여 유효한 토큰을 발급받습니다. 그런 다음 GET/api/v1/data/1234로 요청을 보냅니다. 이 프로세스의 다음 단계는 구문 및 세션 검사로, 표준 WAF는 요청에 문제가 없는지(SQL 인젝션이 없는지) 확인하고 API 게이트웨이는 세션이 유효한지 확인합니다.

바로 이 지점에서 인증 허점이 발생합니다. WAF와 게이트웨이 모두 리소스 1234가 실제로 사용자 A의 소유인지 확인하지 않으며, 백엔드 서비스는 게이트웨이에서 전달된 ‘검증된’ 요청을 무조건 신뢰해 사용자 B의 비공개 데이터를 사용자 A에게 제공합니다. 바로 이 지점에서 침해 사고가 발생합니다.

하지만 고급 API 보안 솔루션을 사용하면 이 새로운 경비원은 입구에서 사용자의 신분증만 확인하는 데 그치지 않고, 사용자가 들어가려는 각각의 방에 출입할 권한이 있는지까지 확인합니다.

‘적용 후’ 시나리오: ID 인식 기반 정책 적용

고급 API 보안 솔루션은 다음 단계를 통해 인증 공백을 해소하고, 로그인한 사용자에게 요청된 객체에 대해 요청된 작업을 수행할 권한이 있는지 검증합니다.

첫 번째 단계에서 시스템은 토큰에서 사용자 ID(사용자 A)를, 요청에서 리소스 ID(1234)를 추출합니다. 그런 다음 학습된 비즈니스 로직 맵을 사용하여 해당 리소스 1234의 소유자가 사용자 A가 아닌 사용자 B임을 식별합니다.

세 번째 단계에서는 ID와 리소스 간 매핑이 로직 검사를 통과하지 못하므로, 요청이 내부 시스템과 상호 작용하도록 허용되기 전에 애플리케이션의 엣지에서 차단됩니다. 따라서 승인되지 않은 요청은 데이터가 저장된 애플리케이션의 백엔드에 도달하지 못하며, 데이터 유출이 시작되기 전에 방지됩니다.

시프트 레프트가 BOLA를 막지 못하는 이유

보안 검사와 테스트를 개발 수명 주기의 초기 단계로 앞당기는 것만으로는 이 문제를 해결할 수 없습니다. 시프트 레프트 전략에는 맥락이 부족하기 때문입니다. 정적 분석(SAST)과 같은 도구는 데이터가 아닌 코드를 살펴보므로, 사용자 A가 사용자 B의 청구서를 볼 권한이 없다는 사실을 알 수 없습니다. 이러한 관계는 소스 코드가 아니라 데이터베이스에 정의되어 있기 때문입니다.

또한 대부분의 동적 분석(DAST) 도구는 단일 사용자의 컨텍스트 내에서만 스캔합니다. 이러한 도구는 “200 OK” 응답을 확인하면 통과로 처리하며, 해당 사용자가 다른 사용자의 비공개 기록에 접근하고 있다는 사실을 인지하지 못합니다.

반대로, 일반적인 API 테스트는 컨텍스트를 인식하지 못합니다. 본질적으로 진공 상태에서 테스트하는 것과 같습니다. 실제 환경의 트래픽 데이터를 무시하기 때문에 제대로 작동하지 않습니다. 테스트가 프로덕션 환경에서 ID A가 리소스 B에 어떻게 매핑되는지 파악하지 못한다면, 논리가 아닌 구문만 검증할 수 있습니다. 이는 비즈니스 로직을 테스트하는 것이 아닙니다.

엣지에서의 정책 적용

이 문제를 해결하려면 조직은 다음으로 구성된 3계층 런타임 전략이 필요합니다:

사용자-리소스 매핑. API 보안 솔루션은 토큰에서 사용자 ID를 추출한 후 HTTP 요청 메시지(헤더, 쿠키, 경로 또는 본문)의 리소스 ID와 비교합니다.
Open Policy Agent(OPA) 사이드카. 수백 명의 개발자가 각자 고유한 검사를 작성하도록 맡기는 대신, OPA를 사용하여 권한 부여 규칙을 하나의 중앙 위치에서 관리하세요. OPA 사이드카는 애플리케이션 컨테이너와 함께 실행되는 배포 패턴으로, 지연 시간이 짧고 성능이 뛰어난 로컬 권한 부여 결정을 제공하여 마이크로서비스 및 API 보안을 위한 정책을 실시간으로 평가할 수 있게 합니다.
행위 모니터링. BOLA 공격을 차단하려면 실시간 트래픽에서 ID(누가), 컨텍스트(어떻게), 리소스(무엇을)를 추출하여 정상적인 관계에 대한 기준선을 수립해야 합니다. 예를 들어 단일 사용자가 1분 동안 서로 다른 ID 50개에 액세스를 시도하는 등 기존 기준선에서 벗어나면 시스템은 이를 이상 징후로 식별합니다. 이는 사람이 아닌 스크레이퍼의 명백한 특징이므로 즉시 차단해야 합니다.

F5의 지원 방식

F5 Distributed Cloud API Security는 가시성이 전혀 없는 상태에서 런타임 보호를 적용하는 단계까지 명확한 경로를 제공합니다. F5 Distributed Cloud Services의 일부로서 애플리케이션 제공과 보안을 하나의 플랫폼에 결합한 통합 보안을 제공합니다. 분산 서비스 거부(DDoS) 공격 완화, 봇 차단, API 보안, WAF 등의 구성 요소 전반에서 인텔리전스를 연계하고 자동화를 활용하여 개별 고객의 요청과 조직적인 다중 벡터 공격을 구분합니다.

이 제품의 API 검색 기능은 ‘섀도 API’를 포함한 모든 API를 자동으로 찾아내고 프로덕션 트래픽을 지속적으로 분석하여 애플리케이션의 실제 비즈니스 로직을 학습하며, 사용자가 특정 데이터 객체와 상호 작용하는 방식을 매핑합니다. 컨텍스트 인식 테스트는 이러한 인사이트를 활용해 사전 프로덕션 환경에서 표적화된 ‘매트릭스 테스트’를 실행함으로써 코드를 배포하기 전에 ID와 객체 간 매핑의 취약점을 식별합니다.

Distributed Cloud API Security는 학습된 행동 기준선과 수신 요청의 상관관계를 분석하여 다양한 BOLA 시나리오를 식별하고 의심스러운 활동을 탐지함으로써 런타임 보호에 활용할 수 있는 BOLA 공격 탐지 기능도 제공합니다.

2026년에는 BOLA 공격이 데이터 침해로 이어지는 가장 빠른 경로 중 하나입니다. 시프트 레프트는 기술적 버그를 찾는 데 효과적이지만, 잘못된 비즈니스 로직을 바로잡는 유일한 방법은 ‘오른쪽에 머무르는 것’입니다. 권한 부여를 엣지로 이동하고 지금 바로 데이터 유출을 차단하세요.

조직의 API 보호를 F5가 어떻게 지원하는지 알아보거나, 실제 작동 모습을 확인해 보세요.