IDOR(취약한 접근 제어)은 URL의 id=124를 125로 바꾸면 남의 청구서가 보이는 결함입니다. 작동 원리와 확실히 막는 법을 살펴봅니다(공격 절차는 다루지 않습니다).
왜 일어나는가
인증(당신이 누구인가)은 통과하지만, 인가(이것을 해도 되는가)가 빠진 것입니다. 인증과 인가는 다릅니다 — 로그인할 수 있다고 해서 그 데이터를 봐도 된다는 뜻은 아닙니다.
| 흔한 빈틈 | 결과 |
|---|---|
| 로그인 후 ID를 그대로 신뢰 | 다른 사용자의 ID로 바꾸면 접근이 성공 |
| "UI에 안 보임 = 안전" 오해 | API를 직접 호출하면 막히지 않음 |
| 생성/수정/삭제에 권한 검사 없음 | 조회뿐 아니라 — 변조와 삭제까지 |
왜 통하는가
ID는 URL의 ?id=에만 나타나지 않습니다. API 경로(/api/orders/125), JSON 본문("userId": 125), 파일 다운로드 URL, 숨겨진 폼 필드 등, 사용자가 보낸 값이 다룰 객체를 고르는 곳이라면 어디든 같은 확인이 필요합니다.
관련 용어
IDOR은 취약한 접근 제어의 한 형태입니다. 여러 이름으로 불리고, 이웃한 개념과 헷갈리기 쉽습니다.
| 용어 | 빠진 것 | 예 |
|---|---|---|
| IDOR | 객체별 소유권/권한 확인 | 사용자 A가 ID를 바꿔 사용자 B의 청구서를 본다 |
| BOLA | IDOR과 같음(OWASP API Security의 이름) | API의 /orders/{id}가 남의 주문을 돌려준다 |
| 기능 단위 인가 결함 | 기능별 권한 확인 | 일반 사용자가 관리자 전용 API를 호출할 수 있다 |
| 취약한 인증 | "누구인가" 확인 자체 | 로그인하지 않아도 API를 호출할 수 있다 |
OWASP Top 10에서 취약한 접근 제어(A01)는 2021년판에 이어 2025년판에서도 1위입니다. API에 초점을 둔 OWASP API Security Top 10(2023)에서도 BOLA가 1위(API1:2023)입니다.
실제 사례: 로그인 후 다른 사람의 데이터가 보였다
이 사이트에서 다룬 두 공공 부문 사례는 공식적으로 시스템 업데이트 중 들어간 결함으로 설명되었지만, 결과는 인가 결함과 같은 모양이었습니다. 로그인한 사용자가 자기 것이 아닌 데이터에 닿을 수 있었습니다.
- 영국 Companies House(2026년 3월): WebFiling에 로그인한 사용자가 특정 조작으로 다른 회사 임원의 자택 주소 등을 볼 수 있었을 가능성이 있고, 권한 없는 제출도 기술적으로 가능했습니다. 기관은 외부 공격이 아니라 2025년 10월 시스템 업데이트에서 생긴 결함이라고 밝혔습니다 → 상세 기사(영문)
- 일본 국세청 e-Tax(2026년 9월): 마이페이지 업데이트의 결함으로 다른 사용자가 79명의 증여세 신고서와 관련 서류를 볼 수 있었습니다 → 상세 기사(영문)
두 사례 모두 로그인 확인은 작동했습니다. 빠진 것은 "이 사용자가 이 객체를 다뤄도 되는가"였습니다. 그리고 둘 다 변경 후에 일어났습니다. 제대로 만든 것이라도 기능을 추가할 때 확인이 빠질 수 있기 때문에, 매번 도는 자동 테스트가 가치가 있습니다.
방어: 매번 서버 측에서 소유권/권한을 검증하라
객체별 소유권/권한 검사(가장 중요)
데이터를 반환하거나 수정하기 직전에, 로그인된 사용자가 그 객체를 소유하거나 권한이 있는지를 서버 측에서 검증하세요. 아니면 거부합니다. 예를 들어 청구서 125를 불러올 때, "125가 존재하는가"만이 아니라 "125가 지금 로그인된 사용자의 것인가"까지 같은 요청 안에서 확인해야 합니다.
기본 거부
새 엔드포인트는 "명시적으로 허용된 것 외에는 전부 거부"에서 출발해, 잊은 검사가 열린 채가 아니라 닫힌 채로 실패하게 하세요.
'자기 것'인 행만 조회
소유자 조건을 쿼리 자체에 녹이세요(예: 현재 사용자 id로 필터). 이렇게 하면 권한 없는 행은 애초에 결과에 포함되지 않으므로, 검사를 빠뜨려도 데이터가 새지 않습니다. 모든 것을 하나의 공유 인가 헬퍼로 통과시켜 어느 호출 지점도 빠뜨리지 않게 하세요.
UI 제어를 방어로 착각하지 않기
버튼을 숨기는 것은 UX이지 보안이 아닙니다. API가 직접 호출된다고 가정하고 서버에서만 결정하세요. 랜덤 ID는 보조로 두되, 통제 수단으로 두지 마세요.
내 앱에서 확인하는 방법
직접 만들거나 관리하는 앱에서만 하세요. 남의 서비스에서 시도하면 부정 접근이 될 수 있습니다.
- 테스트 사용자 A와 B를 만들고, 각자 레코드(주문, 파일 등)를 하나씩 갖게 합니다
- A로 로그인한 상태에서 B의 레코드를 가리키는 ID로 조회, 수정, 삭제 API를 호출합니다. UI가 아니라 개발자 도구나 API 클라이언트에서 API를 직접 호출하세요
- 모든 요청이 403이나 404로 거부되는지 확인합니다. 목록 API에 B의 레코드가 섞이지 않는지도 확인하세요
- 이것을 자동 테스트로 만들고, 엔드포인트를 추가할 때마다 같은 테스트를 더합니다
OWASP API Security Top 10도 인가 메커니즘을 평가하는 테스트를 작성하고, 그 테스트가 실패하는 변경은 배포하지 말라고 권장합니다.
본 사이트의 견해: 놓치기 쉽지만 영향이 크므로 자동 테스트로 확인한다
IDOR은 기술적으로 밋밋해 코드 리뷰에서 놓치기 쉽지만, 영향은 심각합니다("한 번의 클릭으로 모두의 개인 데이터가 드러남"). 그래서 실용적인 방법은 자동화된 테스트를 추가하는 것입니다: 다른 사용자로서 남의 ID를 요청하면 반드시 403을 반환해야 한다. 본 사이트의 원칙은 "클라이언트 UI에서 절대 방어하지 않고, 서버에서만 결정한다"입니다. 인가는 매 요청마다 메커니즘으로 강제되어야 하며 — 결코 사람의 주의력에 맡겨서는 안 됩니다.
출처(1차 자료)
- OWASP Top 10:2025, "A01 Broken Access Control" — top10.owasp.org(순위, 안전하지 않은 직접 객체 참조의 예)
- OWASP API Security Top 10 2023, "API1:2023 Broken Object Level Authorization" — api-security.owasp.org(예방책, 테스트 권장)
- MITRE CWE-639: Authorization Bypass Through User-Controlled Key — cwe.mitre.org
- 두 사례의 출처(Companies House와 일본 국세청의 발표)는 각 사례 기사에 실려 있습니다
다음으로 읽기
- 학습: 인증과 인가의 차이(로그인＝인가가 아니다; IDOR은 이 '인가 누락'의 한 형태)
- 사례: Companies House WebFiling 결함(영문) · e-Tax 증여세 신고서가 다른 사용자에게 보인 사고(영문)
- 용어집: CSRF란(로그인 상태를 악용하는 공격) · OWASP Top 10이란 · 세션 고정이란
- 기초: 보안 기초 · 무료 보안 도구