직접 객체 참조 취약점(Insecure Direct Object Reference)이란?
직접 객체 참조 취약점(IDOR)은 애플리케이션 요청에서 객체 식별자를 조작함으로써 공격자가 다른 사용자의 데이터에 접근할 수 있도록 하는 접근 제어 취약점입니다. 애플리케이션이 데이터베이스 키, 파일 이름, 또는 레코드 ID를 사용자에게 직접 노출하고, 요청한 사용자가 해당 객체의 소유자인지 검증하지 않을 경우, 인증된 사용자는 URL의 숫자만 변경하여 다른 사용자의 데이터를 조회하거나 수정할 수 있습니다.
IDOR는 기록상 가장 큰 데이터 노출 사고의 원인이 되었습니다. 2019년, First American Financial Corporation은 애플리케이션이 누구나 URL 파라미터를 변경해 다른 사용자의 문서에 접근할 수 있도록 허용하여, 사회보장번호와 은행 계좌 정보가 포함된 8억 장 이상의 이미지를 노출시켰습니다.
핵심적인 실패 원인은 단순합니다. 애플리케이션은 사용자가 로그인했는지(인증)는 확인하지만, 특정 레코드에 접근할 권한이 있는지(인가)는 확인하지 않습니다. 즉, 애플리케이션은 현관문의 잠금은 확인하지만, 내부의 모든 서류함은 누구나 열 수 있도록 허용합니다.
IDOR는 CWE-639: 사용자 제어 키를 통한 인가 우회로 매핑됩니다. API 맥락에서는 동일한 취약점이 Broken Object Level Authorization(BOLA)로 불리며, OWASP API1 (API1:2023)에서 1위를 차지합니다. 상위 카테고리인 Broken Access Control은 OWASP Top 10에서 1위에 위치하며, 2025년 판에서도 그 위치를 유지하고 있습니다.
구체적인 동작 방식을 살펴보기 전에, IDOR가 어떤 형태로 나타나는지와 주요 취약점 프레임워크 내에서의 위치를 이해하는 것이 도움이 됩니다.
.jpg)
직접 객체 참조 취약점의 유형
IDOR는 단일한 결함이 아닙니다. 권한 관계와 노출되는 객체 유형에 따라 다양한 형태로 나타납니다.
수평적 IDOR
가장 일반적인 형태입니다. 인증된 사용자가 동일 권한 수준의 다른 사용자의 객체에 접근하는 경우로, /api/users/123/profile을 /api/users/124/profile로 변경하여 다른 계정의 데이터를 읽는 방식입니다. 권한 상승은 발생하지 않으며, 공격자는 동일 계층 내에서 계정 경계를 넘나듭니다.
수직적 IDOR
공격자가 자신이 가진 권한보다 더 높은 권한이 필요한 객체에 접근하는 경우입니다. 예를 들어, 관리자 레코드, 제한된 구성 엔드포인트 또는 관리 기능에 식별자 조작을 통해 접근합니다. 수직적 IDOR는 종종 전체 권한 상승으로 이어지며, Honda eCommerce 사례에서는 연구원이 딜러 수준에서 플랫폼 관리자 권한까지 상승했습니다.
API IDOR (BOLA)
REST 및 GraphQL API에서는 동일한 결함이 Broken Object Level Authorization(BOLA)로 불립니다. API의 무상태 특성으로 인해 이 변종은 특히 만연합니다. 단 하나의 잘못 구성된 리졸버나 라우트 핸들러가 인증된 모든 세션에 컬렉션 내 모든 레코드를 노출할 수 있습니다.
정적 리소스 IDOR
파일 다운로드, 내보내기, 보고서 엔드포인트는 인가 검토 시 자주 누락됩니다. 애플리케이션이 /reports/invoice_1042.pdf에서 요청 사용자가 해당 인보이스의 소유자인지 확인하지 않고 PDF를 제공한다면, 이 취약점은 데이터베이스 레코드 IDOR와 구조적으로 동일합니다. 이 변종은 의료, 금융, 법률 플랫폼에서 규제 데이터를 포함한 문서에 흔히 나타납니다.
각 형태는 취약점 프레임워크 내에서 별도의 위치에 매핑되며, 이로 인해 IDOR의 분류가 복잡해집니다.
OWASP의 직접 객체 참조 취약점 분류
IDOR는 세 가지 별도의 취약점 프레임워크에 등장하며, 각각 동일한 근본적 실패에 대한 조직적 관점을 반영합니다.
| Framework | Entry | Name | Current Position |
| OWASP Top 10 (2007–2013) | A4 | Insecure Direct Object References | Standalone; deprecated as a separate entry |
| OWASP Top 10 (2021–2025) | A01 | Broken Access Control | #1 (maps 40 CWEs, including CWE-639) |
| OWASP API Security Top 10 | API1:2023 | Broken Object Level Authorization (BOLA) | #1 (Easy exploitability, Widespread prevalence) |
| MITRE CWE | CWE-639 | Authorization Bypass Through User-Controlled Key | 2025 CWE Top 25 |
OWASP Top 10 내 위치
IDOR는 2007년부터 2013년까지 독립된 Top 10 항목이었습니다. 2017년 OWASP는 이를 Broken Access Control로 통합했으며, 2021년 1위로 상승했고 2025년 판에서도 1위를 유지하며 40개의 CWE를 이 카테고리로 매핑합니다.
OWASP API Security Top 10
IDOR의 API 특화 프레이밍인 BOLA는 2019년 API Security Top 10이 도입된 이후 API1 위치를 유지하고 있습니다. API1:2023 항목은 BOLA의 악용 용이성("Easy")과 만연도("Widespread") 모두에서 최고 등급을 부여하며, 이는 다른 어떤 API 취약점보다 더 많은 보고가 발생하는 이유입니다.
CWE 매핑
CWE-639 (사용자 제어 키를 통한 인가 우회)는 IDOR의 주요 MITRE 분류입니다. 상위 항목은 CWE-284(부적절한 접근 제어)입니다. SQL 기반 구현에 가장 구체적인 하위 항목은 CWE-566(사용자 제어 SQL 기본 키를 통한 인가 우회)입니다. CWE-639는 2025 CWE Top 25에 포함되어 있습니다.
이 분류 체계를 이해하면 실제로 취약점이 어떻게 악용되는지 살펴볼 수 있습니다.
직접 객체 참조 취약점의 동작 원리
IDOR는 애플리케이션이 인증과 인가 사이의 근본적 간극을 악용합니다. 아래 단계는 단일 노출 식별자가 어떻게 대규모 데이터 유출로 이어지는지 설명합니다.
1단계: 애플리케이션이 직접 객체 참조를 노출
애플리케이션이 내부 객체에 직접 매핑되는 URL 또는 API 파라미터를 생성합니다:
123 값은 사용자 레코드의 데이터베이스 기본 키로, URL 경로에 직접 노출됩니다.
2단계: 공격자가 식별자를 변경
공격자가 123을 124로 변경합니다. 애플리케이션이 사용자 124의 프로필 데이터를 반환하면, 취약점이 확인됩니다.
3단계: 서버가 인가 검증 없이 객체를 조회
OWASP 참조는 명확한 취약 코드 패턴을 제공합니다
@login_required 데코레이터는 사용자가 로그인했는지만 확인합니다. 사용자 123이 사용자 124의 프로필에 접근할 수 있는지 검증하지 않습니다. 한 줄만 추가하면 취약점이 해결됩니다:
4단계: 열거를 통한 대규모 악용
공격자가 패턴이 동작함을 확인하면, 가능한 ID 값을 반복하는 스크립트를 작성하여 단일 취약점을 대규모 데이터 유출로 확장합니다. 애플리케이션에 따라 이 열거는 빠르게 완료될 수 있습니다. 악용 속도가 단일 접근 제어 결함을 대규모 데이터 유출로 전환시키는 요인입니다.
네 가지 주요 공격 표면
| Surface | Example |
| URL 경로 파라미터 | /invoices/1042를 /invoices/1043으로 변경 |
| 쿼리 스트링 파라미터 | ?order_id=7001을 ?order_id=7002로 변경 |
| 파일 파라미터 | ?file=report_user1.pdf를 ?file=report_user2.pdf로 변경 |
| POST 본문 숨김 필드 | 폼 제출 시 user_id를 다른 사용자의 ID로 변경 |
이러한 공격 표면은 애플리케이션 설계 및 구축 방식의 구조적 원인에서 비롯됩니다.
직접 객체 참조 취약점의 원인
IDOR는 구조적 설계 결정과 개발자의 일반적인 오해가 애플리케이션 아키텍처 전반에 누적되어 발생합니다.
인가 누락 및 범위 지정 없는 쿼리
주요 원인은 사용자가 제공한 입력값을 이용해 객체를 조회하면서, 요청 사용자가 해당 레코드의 소유자인지 검증하지 않는 애플리케이션입니다. 이는 범위 지정 없는 데이터베이스 쿼리에서 가장 흔히 나타납니다. 즉, 애플리케이션이 전체 객체 테이블을 쿼리((Order.find(order_id)))하는 대신, 인증된 사용자의 데이터셋만 쿼리((current_user.orders.find(order_id)))해야 하지만 이를 누락하여 모든 레코드를 인증된 세션에 노출합니다.
예측 가능한 식별자 및 직접 키 노출
MITRE CWE-639는 이를 명시적으로 지적합니다. 순차적이거나 쉽게 추측 가능한 레코드 ID를 사용하는 시스템은 공격자가 값을 증가시키는 방식으로 다른 사용자의 데이터를 열거할 수 있습니다. 데이터베이스 기본 키를 URL이나 POST 본문에 직접 노출하는 것은(특히 정수 시퀀스 1, 2, 3…) 매우 예측 가능한 공격 표면을 만듭니다.
UUID에 대한 오해
OWASP 치트시트는 이를 직접 언급합니다. GUID와 같은 복잡한 식별자는 유효한 값을 추측하기 어렵게 만들지만, 접근 제어 검증은 여전히 필수입니다. 공격자가 공유 링크나 애플리케이션 응답을 통해 유효한 URL을 획득할 경우, 애플리케이션은 인가되지 않은 접근을 반드시 차단해야 합니다.
무상태 API 아키텍처
OWASP API1:2023은 API에 특화된 구조적 원인을 지적합니다. 서버가 클라이언트에서 전달된 객체 ID와 같은 파라미터에 의존해 접근할 객체를 결정하는 구조입니다. REST 및 GraphQL API는 명시적 요청별 인가 로직이 없으면 구조적으로 IDOR에 취약합니다.
이러한 원인이 해결되지 않으면, 결과 취약점은 기술적 계층을 넘어 비즈니스에 심각한 영향을 미칩니다.
직접 객체 참조 취약점의 영향 및 위험
IDOR의 영향은 데이터 노출에서 계정 탈취까지 다양하며, 규제, 재정, 안전 영역까지 확장됩니다.
대규모 데이터 노출
IDOR 악용은 스크립트화가 가능하므로, 단일 취약 엔드포인트로 전체 데이터베이스가 노출될 수 있습니다. First American의 IDOR는 8억 장 이상의 이미지를 노출시켰습니다. Optus는 접근 제어가 깨진 API 엔드포인트로 고객 기록을 유출했습니다.
규제 및 재정적 제재
IDOR 유출은 수년에 걸친 규제 집행을 유발합니다. First American은 SEC와 NYDFS로부터 제재를 받았습니다. Optus 역시 상당한 재정적 피해를 입었습니다.
계정 탈취 및 권한 상승
IDOR는 단순히 데이터 조회에 그치지 않습니다. Honda eCommerce 플랫폼 사례에서는 연구원이 단일 ID 값을 변경해 모든 딜러의 기록에 접근했고, 이후 플랫폼 관리자(혼다 직원 전용)로 권한을 상승시켰습니다.
OWASP 심각도 등급
OWASP API Top 10은 BOLA의 악용 용이성을 "Easy", 만연도를 "Widespread"로 평가합니다. 간단한 악용과 광범위한 만연도의 조합이 1위 위치의 이유입니다.
이 심각도 평가는 공격자가 IDOR를 대규모로 악용하는 방법을 반영합니다.
공격자가 직접 객체 참조 취약점을 악용하는 방법
IDOR 악용은 최소한의 기술적 숙련도로 구조화된 워크플로우를 따릅니다.
파라미터 대체
공격자는 식별자를 다른 사용자의 값으로 변경하고 응답을 관찰합니다. /api/users/123/profile을 /api/users/124/profile로 변경해 200 OK 응답이 오고 403 Forbidden이 오지 않으면 취약점이 확인됩니다.
자동화된 열거
확인 후, 공격자는 Burp Suite의 Intruder 모듈, OWASP ZAP, 또는 커스텀 스크립트를 사용해 가능한 모든 ID 값을 반복합니다. OWASP API 문서는 URL 내 ID를 조작하는 간단한 스크립트로 수천 개의 레코드에 접근하는 방법을 설명합니다.
연쇄적 악용
공격자는 IDOR를 다른 취약점과 결합합니다. Honda eCommerce 사례는 수평적 데이터 접근과 수직적 권한 상승이 연쇄적으로 발생한 예입니다. McDonald's McHire 플랫폼은 IDOR와 기본 자격 증명이 결합되어 노출이 심화되었습니다.
수평 및 수직 접근
OWASP 접근 제어 가이드는 이 구분을 명확히 합니다. IDOR는 대부분 수평적 권한 상승(동일 권한 내 사용자 간 데이터 접근)을 가능하게 하며, 드물게 수직적 상승(일반 사용자가 관리자 권한 획득)도 발생합니다.
이러한 기법의 단순성으로 인해 사용자 데이터를 처리하는 거의 모든 애플리케이션이 공격 대상이 될 수 있습니다.
직접 객체 참조 취약점의 영향 대상
IDOR는 사용자 제어 식별자를 이용해 객체에 접근하면서, 요청별 인가 검증이 없는 모든 애플리케이션에 영향을 미칩니다.
고위험 애플리케이션 아키텍처
IDOR 위험은 객체 참조를 더 넓게 노출하거나 인가 검증을 건너뛰기 쉽게 만드는 구조적 패턴에 의해 증폭됩니다.
- 리소스 기반 URL 패턴을 사용하는 REST API.
/resource/{id}규칙을 따르는 모든 API는 설계상 구조적 IDOR 노출이 있습니다. - GraphQL API. 인자 기반 객체 접근에서 리졸버가 소유권 검증을 생략하면 동일한 취약점이 발생합니다.
- 멀티테넌트 SaaS 애플리케이션. 한 테넌트의 사용자가 ID를 조작해 다른 테넌트의 데이터에 접근합니다.
- IoT 및 모바일 API 백엔드. 복잡한 인증 흐름과 제한된 서버 측 상태 관리로 BOLA 노출이 증가합니다.
- 전자상거래 플랫폼. 주문 ID, 인보이스 ID, 고객 계정 참조는 고가치 표적입니다.
이 모든 아키텍처의 공통점은 객체 접근이 클라이언트가 제어하는 식별자에 의해 결정되고, 서버가 데이터 반환 전 소유권 검증을 수행하지 않는다는 점입니다.
고위험 산업군
가장 노출이 큰 산업군은 객체 참조가 민감한 기록, 규제 데이터, 물리적 시스템에 직접 매핑되는 곳입니다.
- 의료: CVE-2024-28320 (병원 관리 시스템, CVSS 7.6)에서 환자 데이터 조회 및 수정이 가능했습니다.
- 금융 서비스: 결제 플랫폼 및 타이틀 회사는 데이터 노출과 규제 위험 모두에 직면합니다.
- 정부: HackerOne에 따르면, 정부 프로그램에서 IDOR가 반복적으로 보고됩니다.
- 자동차: Pandora/Viper 사례와 CVE-2025-11690은 차량 시스템에 대한 실제 위험을 확인합니다.
이 산업군에서 발생한 실제 침해 사례는 IDOR를 방치할 경우의 결과를 보여줍니다.
직접 객체 참조 취약점의 실제 사례
다음 사례들은 IDOR가 다양한 산업 및 애플리케이션 유형에서 어떻게 발생했는지 보여줍니다. 각 사고는 사용자 제공 식별자가 요청자가 반환받는 객체의 소유자인지 서버가 검증하지 않은 동일한 근본적 실패로 귀결됩니다.
First American Financial Corporation (2019)
First American의 EaglePro 애플리케이션은 누구나 URL 파라미터를 변경해 다른 사용자의 에스크로 및 타이틀 문서에 접근할 수 있도록 허용했습니다. 2014년에 도입된 이 취약점은 5년간 지속되었습니다. 사회보장번호와 모기지 결제 문서를 포함해 8억 장 이상의 이미지가 노출되었습니다. 규제 제재는 SEC 공시와 NYDFS 공시에 문서화되어 있습니다. CISA, NSA, 호주 신호국은 IDOR 공동 권고문에서 이 사례를 인용했습니다.
Optus 데이터 유출(2022)
2018년 코딩 오류로 Optus API 엔드포인트의 접근 제어가 깨졌습니다. Optus는 2021년 메인 도메인에서는 오류를 수정했으나, 인터넷에 노출된 도메인은 패치하지 않았습니다. 2022년 9월, 공격자는 깨진 접근 제어를 악용해 고객 기록을 탈취했고, 유효한 개인 식별 번호도 포함되었습니다. 호주 통신미디어청(ACMA)은 이 공격이 "고도로 정교하지 않았으며" "단순한 시행착오"로 수행되었다고 확인했습니다. 이는 호주 최대 규모의 데이터 유출입니다.
McDonald's McHire 챗봇(2025)
보안 연구원 Ian Carroll과 Sam Curry는 McDonald's에서 사용하는 Paradox.ai McHire 챗봇 API에서 IDOR를 발견했습니다. 내부 /api/lead/cem-xhr 엔드포인트에서 lead_id 정수를 감소시켜, 인가 검증 없이 다른 지원자의 전체 채팅 기록, 연락처, 세션 토큰을 조회할 수 있었습니다. 본인 애플리케이션의 lead_id가 64,185,742로, 잠재적으로 접근 가능한 기록의 규모를 보여줍니다. 이 취약점은 2025년 6월 30일 공개되어 당일 수정되었습니다.
Pandora 및 Viper 스마트카 알람(2019)
Pen Test Partners는 스마트카 알람 API에서 IDOR 취약점을 발견해 차량 플릿 전체의 계정 탈취가 가능함을 확인했습니다. 공격자는 계정 비밀번호나 이메일을 변경해 차량에 대한 물리적 제어권을 획득할 수 있었습니다. 연구진은 약 300만 대의 고급 차량이 노출되었다고 추정하며, 벤더는 공개 후 며칠 내에 결함을 패치했습니다.
버그 바운티 신호
IDOR는 버그 바운티 플랫폼에서 지속적으로 높은 가치의 발견 항목입니다. PayPal 보고서는 HackerOne에서 상당한 보상을 받았으며, HackerOne 데이터는 IDOR가 반복적으로 보고되는 취약점임을 보여줍니다.
이 사례들은 IDOR가 주요 취약점 프레임워크와 실제 침해에서 10년 이상 지속되어 왔음을 보여줍니다.
직접 객체 참조 취약점의 연혁 및 역사
IDOR는 거의 20년간 공식 보안 분야의 일부였습니다. 아래 연대표는 독립 명칭 카테고리에서 여러 프레임워크에 내재된 개념으로 발전하고, API, IoT, AI 시스템 등 신기술 인프라로 확장되는 과정을 추적합니다.
| Period | Milestone |
| 2007 | OWASP가 Top Ten에서 "IDOR" 용어를 A4 독립 카테고리로 도입 |
| 2013-2014 | OWASP 독립 카테고리(A4) 마지막 해. First American의 IDOR 결함 도입 |
| 2017 | IDOR가 A5에서 Broken Access Control로 통합 |
| 2019 | OWASP API Security Top 10에서 BOLA를 API1로 도입. First American 공개. Pandora/Viper 노출 문서화 |
| 2021 | Broken Access Control이 OWASP Top 10에서 1위 |
| 2022 | Optus 유출, 호주 최대 데이터 유출 |
| 2023 | CISA/NSA/ACSC가 IDOR 관련 공동 권고문 AA23-208A 발표. BOLA가 API1:2023 유지 |
| 2025 | Broken Access Control이 1위 유지, 40개 CWE 매핑. CWE-639가 2025 CWE Top 25에 등재. McDonald's McHire IDOR가 Ian Carroll과 Sam Curry에 의해 공개 |
| 2024-2026 | IDOR가 AI/LLM 인프라(CVE-2025-4962), 차량 텔레매틱스(CVE-2025-11690), 엔터프라이즈 IAM(CVE-2024-56404)로 확장됨. HackerOne은 IDOR 보고가 증가하고 XSS 및 SQLi는 감소하고 있음을 확인 |
IDOR가 거의 20년간 취약점 추적에서 지속된 만큼, 자체 애플리케이션에서 이를 탐지할 신뢰할 수 있는 방법이 필요합니다.
직접 객체 참조 취약점 탐지 방법
IDOR는 객체 소유권과 비즈니스 로직에 대한 추론이 필요하므로, 도구만으로는 탐지하기 어렵습니다. 단순히 응답 코드 패턴을 매칭하는 것으로는 충분하지 않습니다.
수동 침투 테스트(필수)
OWASP WSTG는 테스트 절차를 정의합니다:
- 사용자 입력이 객체를 직접 참조하는 모든 위치를 매핑합니다.
- 객체 참조에 사용되는 파라미터 값을 변경합니다.
- 다른 사용자의 객체를 조회하거나 인가를 우회할 수 있는지 평가합니다.
- 다양한 HTTP 메서드와 대량 접근 패턴을 테스트합니다.
수동 테스트만이 인가 의도를 파악할 수 있으며, 단순 파라미터 조작만으로는 충분하지 않습니다. 각 사용자 역할이 접근할 수 있는 범위와 그렇지 않은 범위를 이해하는 테스터가 필요합니다.
애플리케이션 보안 테스트 도구
OWASP ZAP, Burp Suite와 같은 DAST 도구는 다중 사용자 테스트 계정과 교차 사용자 객체 ID 매핑을 구성할 경우 IDOR를 탐지할 수 있습니다. 기본 스캐너 설정만으로는 IDOR가 탐지되지 않습니다. SAST 도구는 인가 함수 호출이 누락된 엔드포인트를 플래그할 수 있지만, 런타임에서 인가 로직이 의미적으로 올바른지 판단할 수는 없습니다.
런타임 행위 모니터링
실제 운영 환경에서 IDOR를 현실적으로 탐지할 수 있는 유일한 운영 제어입니다. 다음 신호를 모니터링하십시오:
- 단일 세션에서 객체 참조 엔드포인트로의 순차적 또는 열거 패턴 요청
- 요청 사용자가 소유하지 않은 객체 ID에 대해 200 OK를 반환하는 인증 요청
- 여러 사용자 계정에 걸친 대량 객체 참조 요청
사전 배포 테스트와 달리, 행위 모니터링은 실제 악용이 발생하는 운영 환경에서 지속적으로 동작합니다. 이는 실시간 데이터에 대한 IDOR 악용을 탐지할 수 있는 유일한 제어입니다.
보안 코드 리뷰
인가 치트시트에 따르면, 코드 리뷰는 모든 요청에서 권한이 검증되는지와 접근 제어가 전역적으로 구현되어 있는지 확인해야 합니다. 사용자 제공 식별자를 받는 엔드포인트에 특히 주의하고, 파라미터 입력부터 데이터베이스 쿼리, 응답까지의 코드 경로를 추적하십시오. 인증된 사용자의 권한 범위로 쿼리를 제한하지 않는 모든 경로는 IDOR 위험이 확인된 것입니다.
IDOR를 찾는 것은 첫 단계에 불과합니다. 이를 방지하려면 개발 및 배포 라이프사이클 전반에 걸친 제어가 필요합니다.
직접 객체 참조 취약점 방지 방법
방지는 설계, 개발, 테스트, 런타임 모니터링에 걸친 다계층 접근이 필요합니다.
설계 단계: 모든 기능에 인가 모델링
기능 설계 시 공격 표면 분석에 Broken Access Control을 포함하십시오. 코드 작성 전 명시적 인가 함수(canAccess, isOwner 패턴)를 정의하십시오.
개발 단계: 모든 객체 접근에 서버 측 인가 강제
IDOR 치트시트는 다음 제어를 명시합니다:
- 사용자가 접근 시도하는 모든 객체에 대해 접근 제어 검증을 구현하십시오. 인증된 사용자는 클라이언트 제공 식별자가 아니라 세션 정보를 통해 결정해야 합니다. 인가 검증은 개별 메서드가 아니라 중앙 집중형 미들웨어에서 강제하십시오.
- 데이터베이스 쿼리를 인증된 사용자의 접근 가능한 데이터셋으로 범위 지정하십시오:
외부 값을 내부 DB ID로 변환하는 간접 참조 맵을 사용하고, 인가 검증과 결합하십시오.
공개 식별자로 UUID 또는 긴 난수 값을 채택하십시오. 이는 심층 방어 계층일 뿐, 1차 제어가 아닙니다.
식별자 암호화는 피하십시오. OWASP 치트시트는 "안전하게 구현하기 어렵다"고 명시합니다.
- 정적 리소스에도 인가를 강제하십시오. 이는 인가 치트시트에서 자주 간과되는 표면입니다.
이러한 제어는 클라이언트 제공 값을 신뢰하지 않고 데이터 계층에서 소유권을 강제하기 때문에 효과적입니다. 파라미터를 조작한 공격자는 성공적인 쿼리가 아니라 인가 검증에 막히게 됩니다.
테스트 단계: 다중 사용자 인가 테스트
교차 계정 접근을 테스트하는 다중 사용자 구성으로 DAST 스캔을 실행하십시오. 인가 함수 호출이 누락된 엔드포인트를 플래그하는 SAST 규칙을 포함하십시오. 비즈니스 로직 IDOR에 대해서는 수동 침투 테스트를 우선시하십시오.
운영 단계: API 행위 모니터링
정상 API 접근 패턴을 기준선으로 삼고, 이상 객체 접근을 플래그하는 행위 모니터링을 배포하십시오. SentinelOne의 Storyline 기술은 API 상호작용 전체 시퀀스와 의심스러운 접근 패턴의 신원 컨텍스트를 재구성하여, IDOR 악용 여부를 확인 또는 해제하는 데 필요한 포렌식 타임라인을 제공합니다.
이러한 제어를 효과적으로 구현하려면, 애플리케이션 보안 테스트와 런타임 모니터링 도구의 적절한 조합이 필요합니다.
탐지 및 방지 도구
단일 도구로 IDOR를 완벽히 커버할 수 없습니다. 효과적인 커버리지는 개발 시 스캐닝, 런타임 모니터링, 수동 검증의 다계층 조합이 필요합니다. 아래 도구들은 각 단계별로 서로 다른 커버리지와 한계를 가집니다.
애플리케이션 보안 테스트 도구
| Tool Type | Capability | IDOR Coverage | Limitation |
| DAST (OWASP ZAP, Burp Suite) | HTTP/S를 통한 실행 중 애플리케이션 테스트 | 다중 사용자 구성 시 IDOR 탐지 | 교차 계정 테스트 시나리오 수동 설정 필요 |
| SAST (SonarQube, Checkmarx) | 화이트박스 소스 코드 분석 | 인가 호출 누락 패턴 플래그 | 런타임 인가 로직의 의미적 정확성 검증 불가 |
| IAST (Contrast Security) | QA 테스트 중 인앱 에이전트 | 런타임 행위 기반, 오탐 감소 | 계측된 테스트 환경 필요 |
| 수동 침투 테스트 | 비즈니스 로직, 다중 사용자 시나리오 | 복잡한 IDOR에 대한 유일한 신뢰 방법 | 시간 소모, 숙련된 테스터 필요 |
API 보안 및 행위 모니터링
행위 기반 API 모니터링 도구는 정상 접근 패턴의 기준선을 구축하고 이상을 플래그합니다. 이는 운영 환경에서 IDOR 악용을 현실적으로 탐지할 수 있는 유일한 런타임 제어입니다. IDOR 요청은 합법적 트래픽과 구문상 동일하기 때문입니다.
관련 취약점
IDOR는 Broken Access Control 계열에 속합니다. 관련 취약점 유형과의 관계를 이해하면, 대응 우선순위를 정하는 데 도움이 됩니다.
- Broken Object Level Authorization (BOLA), API1:2023. IDOR와 BOLA 모두 CWE-639에 매핑됩니다. BOLA는 동일한 근본적 실패의 API 특화 프레이밍입니다.
- Broken Function Level Authorization (BFLA), API5:2023 / CWE-285. IDOR가 데이터 객체(접근 가능한 레코드)를 대상으로 한다면, BFLA는 API 기능(수행 가능한 작업)을 대상으로 하며, 주로 수직적 권한 상승을 유발합니다.
- Forced Browsing (CWE-425). 네비게이션 및 페이지 수준 제어를 우회해 제한 페이지에 직접 접근하는 것으로, Broken Access Control의 구체적 예시로 등재되어 있습니다.
- SQL 기본 키 인가 우회(CWE-566). CWE-639의 직접 하위 항목으로, SQL 기반 IDOR 구현에 가장 구체적인 CWE입니다.
- 수직적 권한 상승(CWE-269 / CWE-285). 공격자가 식별자를 조작해 관리자 기능에 접근할 때, IDOR는 권한 상승과 연쇄적으로 발생할 수 있습니다. Honda eCommerce 사례가 대표적입니다.
여러 CVE가 이러한 관련 취약점 패턴이 실제 시스템에서 어떻게 나타나는지 보여줍니다.
관련 CVE
| CVE ID | Description | Severity | Affected Product | Year |
| Tableau Server tab-doc API 모듈의 CWE-639 IDOR; 인접 네트워크의 공격자가 사용자 제어 키를 조작해 인가를 우회하고 운영 데이터베이스 클러스터에 접근 | HIGH | Salesforce Tableau Server (<2025.1.3) | 2025 | |
| Tableau Server set-initial-sql tabdoc 명령의 CWE-639 IDOR; 인증된 저권한 사용자가 사용자 제어 파라미터를 조작해 운영 데이터베이스 클러스터에 접근 | HIGH | Salesforce Tableau Server (<2025.1.3) | 2025 | |
| Chainlit 스레드 리소스 처리의 CWE-639 IDOR; 인증 사용자가 소유권 검증 없이 다른 사용자의 스레드 ID를 제공해 대화 데이터에 접근 | MEDIUM | Chainlit | 2025 | |
| Five Star Restaurant Reservations WordPress 플러그인의 CWE-639 IDOR; 인증되지 않은 공격자가 예약 식별자를 조작해 다른 사용자의 기록을 접근, 수정, 삭제 | MEDIUM | Five Star Restaurant Reservations WP plugin (≤2.7.8) | 2025 | |
| One Identity Identity Manager의 IDOR로 온프레미스 설치에서 권한 상승 허용; 공격자가 객체 참조를 조작해 할당된 역할을 초과하는 권한을 획득 | CRITICAL | One Identity Identity Manager 9.x (<9.3) | 2024 | |
| SO Planning 도구의 인증되지 않은 IDOR; 공개 보기가 활성화된 경우, 공격자가 내보내기 엔드포인트를 직접 요청해 전체 데이터베이스를 CSV로 다운로드 | CRITICAL | SO Planning (<1.52.02) | 2024 | |
| WooCommerce Stripe Payment Gateway의 인증되지 않은 IDOR; 주문 소유권 검증 누락으로 90만 개 이상의 활성 설치에서 모든 주문의 청구 이름, 이메일, 주소가 인증되지 않은 사용자에게 노출 | HIGH | WooCommerce Stripe Payment Gateway WP plugin (≤7.4.0) | 2023 | |
| ExtremePacs Extreme XDS 의료 영상 플랫폼의 CWE-639 IDOR; 사용자 제어 키 조작으로 인가 없이 다른 환자의 영상 기록에 접근 | HIGH | ExtremePacs Extreme XDS (<3914) | 2023 | |
| 공유 스토커웨어 백엔드 서버의 IDOR로 수십만 대 기기의 문자, 통화 기록, 사진, 위치 데이터 노출; CISA/NSA/ACSC 권고문 AA23-208A에서 명시적으로 언급 | HIGH | 1byte / 다수 스토커웨어 앱 | 2022 | |
| Telos Alliance Omnia MPX Node의 비밀번호 재설정 기능 IDOR; 공격자가 임의 사용자의 계정 식별자를 제공해 비밀번호를 재설정, 관리자 계정 포함 전체 계정 탈취 가능 | HIGH | Telos Alliance Omnia MPX Node (1.0.0–1.4.x) | 2022 |
결론
직접 객체 참조 취약점은 입력 처리만이 아니라 객체 수준 인가를 깨뜨리기 때문에 가장 많이 악용되는 웹 보안 실패 중 하나로 남아 있습니다. 애플리케이션이 사용자 제공 식별자를 소유권 검증 없이 신뢰한다면, 작은 URL 변경이 대규모 데이터 노출로 이어질 수 있습니다.
모든 객체 접근에서 인가를 강제하고, 다중 사용자 맥락에서 테스트하며, 운영 환경에서 악용을 모니터링함으로써 이러한 위험을 줄일 수 있습니다.
자주 묻는 질문
IDOR는 레코드 소유권 강제 적용 실패입니다. 서버가 사용자가 특정 객체에 접근할 수 있는지 검증하지 않으면, 파일명, 주문 번호, 프로필 ID를 변경하는 것만으로도 타인의 데이터가 노출되거나 변경될 수 있습니다. 실제로 IDOR는 우선적으로 권한 부여 문제이며, 그 다음이 매개변수 조작 문제입니다.
예. 이전 OWASP 자료에서는 IDOR로 명시되어 있지만, 최신 가이드에서는 Broken Access Control로 분류됩니다. API 중심 팀에서는 동일한 취약점을 BOLA라고 부르기도 합니다.
다양한 명칭이 동일한 근본 원인, 즉 객체 수준 권한 부여 누락을 가리킵니다.
예. 공격자는 일반적으로 도달 가능한 엔드포인트와 요청을 보낼 수 있는 유효한 방법만 필요합니다. 코드 실행이나 악성코드 배포가 반드시 필요하지는 않습니다.
하나의 객체 참조 패턴이 동작하면, 스크립트화된 요청을 통해 악용이 확장될 수 있으므로, 방치된 도메인, 구버전 API, 노출된 모바일 백엔드가 특히 위험합니다.
객체 조회가 클라이언트 입력에 의해 결정되는 애플리케이션이 가장 취약합니다. 많은 객체 참조를 노출하거나, 테넌트 간 인프라를 공유하거나, 클라이언트가 전송한 ID를 반복적으로 신뢰하는 무상태 API에 의존하는 시스템에서 위험이 증가합니다. 주요 작업에는 사용자 연동 레코드의 조회, 수정, 내보내기, 삭제가 포함됩니다.
공격자는 애플리케이션이 객체 명명 방식을 드러내는 지점, 즉 URL의 ID, 숨겨진 폼 필드, JSON 본문, API 응답 등에서 시작합니다. 이후 값을 교체하고, 응답을 비교하며, 다양한 방법이나 계정 컨텍스트를 테스트합니다.
상태 코드, 응답 크기, 반환 필드의 작은 차이만으로도 악용 가능한 객체 접근이 확인될 수 있습니다.
가장 초기 징후는 일반적으로 행위 기반입니다. 하나의 인증된 계정이 다수의 객체 ID를 요청하거나, 예상되는 계정 또는 테넌트 경계를 넘어서거나, 정상 사용자 행위와 일치하지 않는 순서로 레코드에 접근하는지 주시해야 합니다.
IDOR는 정상 HTTP 트래픽 내에 숨어있는 경우가 많으므로, 구문보다 맥락이 더 중요합니다.
심각도는 CVSS와 같은 점수뿐만 아니라, 확장성과 신뢰성에서 비롯됩니다. 많은 취약점은 복잡한 익스플로잇 체인을 필요로 하지만, IDOR는 소유권 검증이 누락된 경우 정상 애플리케이션 동작만으로도 악용될 수 있습니다.
노출된 객체에 따라 제한된 데이터 유출부터 계정 탈취, 권한 상승까지 영향을 미칠 수 있습니다.
경우에 따라 가능합니다. 노출된 객체가 비밀번호 재설정, 관리자 설정, 테넌트 경계, 워크플로우 동작을 제어하는 경우, IDOR는 더 큰 탈취의 첫 단계가 될 수 있습니다.
객체의 비즈니스 기능에 따라 취약점이 한 레코드에 국한될지, 플랫폼 전체로 확장될지가 결정됩니다.
기본적으로는 어렵습니다. 도구는 입력값을 찾고 요청을 재생할 수 있지만, IDOR는 누가 어떤 객체를 소유해야 하는지와 세션별 역할 차이를 이해해야 합니다.
가장 효과적인 접근법은 자동화와 준비된 다중 사용자 테스트 데이터, 수동 검증을 결합하는 것입니다. 운영 환경에서는 스캐너에만 의존하기보다 행위 기반 모니터링이 더 현실적입니다.
객체 참조가 민감한 레코드, 규제 데이터, 물리적 세계에 직접 연결되는 환경이 가장 위험합니다. 실제로는 의료 기록, 금융 문서, 정부 데이터, 자동차 시스템, 신원 관리 자산 등이 해당됩니다.
이러한 환경에서는 무단 객체 접근 한 건만으로도 과도한 개인정보, 규제, 사기, 안전 문제가 발생할 수 있습니다.
