웹·모바일 서비스 취약점 점검을 진행하다 보면, 매번 빠지지 않고 발견되는 유형이 있습니다.
바로 취약한 접근통제(Broken Access Control)입니다.
2025년 11월 공개된 OWASP Top 10:2025에서도 이 항목은 여전히 1위를 지키고 있는데요. 이번 판에서는 점검 대상 애플리케이션의 100%에서 어떤 형태로든 접근통제 결함이 발견되어 발생 빈도 1위를 기록했습니다.
이번 글에서는 실제 점검 현장에서 이 유형이 왜 계속 발견되는지, 그리고 어떻게 찾고 어떻게 리포팅하는지 실무 관점에서 정리해 보았습니다.
1. 왜 매년 1위일까요?
접근통제는 인증(로그인을 했는가)이 아니라 인가(이 데이터를 볼 권한이 있는가)의 문제입니다. 로그인은 대부분 프레임워크가 처리해 주지만, 인가는 각 API와 화면마다 개발자가 직접 챙겨야 합니다. 화면 수만큼, 엔드포인트 수만큼 검증 지점이 늘어나고, 그중 단 하나만 빠져도 취약점이 됩니다.
최근에는 AI 코딩 어시스턴트로 생성한 코드가 늘면서, 기능은 정상 동작하지만 인가 검증이 누락된 채 배포되는 사례가 많아졌습니다. 애플리케이션은 매일 변경되는데 점검은 연 1회에 그치는 경우가 많아, 그 사이 새로 추가된 엔드포인트에 접근통제가 빠져 있는 경우를 자주 확인하게 됩니다.
무엇보다 이 유형은 자동화 스캐너로 탐지하기 어렵습니다. 스캐너는 ‘이 요청이 200을 반환하는가’는 알 수 있어도, ‘이 사용자가 이 데이터를 볼 권한이 있는가’는 판단하지 못하기 때문입니다.
데이터가 정상 반환됐는지 여부는 결국 사람만이 판정할 수 있습니다. 그래서 사람이 직접 수행하는 모의해킹에서 그 가치가 가장 선명하게 드러나는 영역이기도 합니다.
2. 현장에서 가장 많이 발견되는 패턴
(1) IDOR (Insecure Direct Object Reference)
가장 흔하고, 임팩트도 큰 유형입니다. 요청 파라미터의 식별자를 변경해 다른 사용자의 데이터에 접근하는 방식입니다.
GET /api/v1/orders/1024 → 본인 주문
GET /api/v1/orders/1023 → 타인 주문 (접근 시 취약)
순차 증가하는 정수 ID가 대표적이지만, UUID를 사용한다고 안전한 것은 아닙니다.
UUID가 응답 어딘가(다른 API의 목록, 이메일, 클라이언트 코드, 캐시 등)에 노출되면 그대로 대입할 수 있기 때문입니다.
핵심은 ‘예측이 가능한가’가 아니라 ‘서버가 소유권을 검증하는가’에 있습니다.
OWASP도 이를 CWE-639(사용자 제어 키를 통한 인가 우회)로 명확히 분류합니다.
식별자는 URL 경로뿐 아니라 쿼리스트링, 요청 본문(JSON), 헤더, 쿠키, multipart 필드에도 숨어 있습니다.
(2) 권한 상승
일반 사용자가 관리자 기능을 호출하는 경우입니다. 화면(UI)에서는 관리자 메뉴가 보이지 않더라도, API는 그대로 열려 있는 사례가 많습니다.
POST /api/admin/users/1024/role
{ "role": "admin" }
프론트엔드에서 버튼만 숨기고 백엔드 인가 검증을 누락한 전형적인 사례입니다.
요청 본문에 isAdmin, role 같은 필드를 끼워 넣거나(Mass Assignment), JWT·쿠키·히든 필드를 변조해 권한을 올리는 시도가 여기 해당하며, 이런 메타데이터 조작은 2025년판에서 접근통제 결함으로 명시됐습니다.
(3) 권한 간 이동 및 메서드별 인가 누락
같은 권한 사용자 간 이동, 하위 권한에서 상위 권한으로의 이동 외에도, 특정 HTTP 메서드에만 인가가 빠지는 경우가 있습니다.
GET은 막았지만 PUT·DELETE·PATCH는 막지 않은 사례가 대표적이므로, 메서드별로 반드시 구분해 점검해야 합니다.
(4) 중요 페이지의 비인증 접근
인증이 필요한 페이지나 관리자 전용 URL을 비로그인 상태로 직접 요청해 접근되는 경우입니다.
curl 한 줄이면 프론트엔드의 화면 제어를 그대로 우회할 수 있습니다.
$ curl https://example.com/app/admin_getappInfo
3. 점검 방법
접근통제 점검의 핵심은 최소 2개 이상의 계정입니다. 권한이 서로 다른 계정을 준비한 뒤 세션을 교차하며 검증합니다.
(예: A : 일반 사용자 / B : 관리자)
유의사항 : 응답 코드만 보지 말고 응답 본문까지 확인해야 합니다. 200 OK라도 빈 데이터인지 실제 타인의 데이터인지에 따라 판정이 갈리며, 이를 통해 오탐·미탐을 줄일 수 있습니다.
심화 취약점 사항 확인
- 노출 데이터의 민감도
: 단순 조회 수준인지, 개인정보(주민등록번호·연락처·결제정보)까지 노출되는지 확인합니다. - 대상 범위
: 특정 1명에 한정되는지, 전체 사용자 접근 및 확인이 가능한지 확인합니다 (자동화로 대량 수집이 가능하면 위험도 상향). - 행위 유형
: 읽기만 가능한지, 수정·삭제까지 가능한지 확인합니다. - 인증 필요 여부
: 로그인 없이 접근 및 사용이 가능한지 확인 합니다.
4. 조치 방안
- 모든 데이터 접근은 서버에서 소유권·권한을 검증합니다
- 인가 로직은 미들웨어·정책 엔진으로 중앙화하고 기본은 거부(deny-by-default)로 둡니다.
- UUID는 완화책일 뿐, 근본 대책은 서버 측 검증입니다.
- JWT는 짧은 만료·서명 검증, 로그아웃 시 세션 무효화, 권한 필드는 클라이언트 입력을 신뢰하지 않습니다.
- 인가 실패 로깅·알림과 레이트 리밋으로 순회 시도를 탐지·차단합니다.
- 신규·변경 엔드포인트마다 인가 테스트를 CI에 포함해 회귀를 방지합니다.
핵심 요약
- 점검은 권한이 다른 계정 2개 이상으로 세션을 교차하며, 응답 코드가 아닌 응답 본문까지 확인해 오탐·미탐을 줄입니다.
- 식별자 점검에 그치지 말고 SSRF·CSRF·CORS·JWT 메타데이터 조작까지 함께 확인합니다.
- 근본 대책은 UUID가 아니라 서버 측 소유권 검증과 deny-by-default입니다.
※ 참고 자료
· OWASP Top 10:2025 — A01: Broken Access Control
· OWASP Web Security Testing Guide — Authorization Testing
· OWASP Cheat Sheet — Authorization
· OWASP Application Security Verification Standard — V8 Authorization
· MITRE CWE-639 — Authorization Bypass Through User-Controlled Key
웹·모바일 서비스 취약점 점검을 진행하다 보면, 매번 빠지지 않고 발견되는 유형이 있습니다.
바로 취약한 접근통제(Broken Access Control)입니다.
2025년 11월 공개된 OWASP Top 10:2025에서도 이 항목은 여전히 1위를 지키고 있는데요. 이번 판에서는 점검 대상 애플리케이션의 100%에서 어떤 형태로든 접근통제 결함이 발견되어 발생 빈도 1위를 기록했습니다.
이번 글에서는 실제 점검 현장에서 이 유형이 왜 계속 발견되는지, 그리고 어떻게 찾고 어떻게 리포팅하는지 실무 관점에서 정리해 보았습니다.
1. 왜 매년 1위일까요?
접근통제는 인증(로그인을 했는가)이 아니라 인가(이 데이터를 볼 권한이 있는가)의 문제입니다. 로그인은 대부분 프레임워크가 처리해 주지만, 인가는 각 API와 화면마다 개발자가 직접 챙겨야 합니다. 화면 수만큼, 엔드포인트 수만큼 검증 지점이 늘어나고, 그중 단 하나만 빠져도 취약점이 됩니다.
최근에는 AI 코딩 어시스턴트로 생성한 코드가 늘면서, 기능은 정상 동작하지만 인가 검증이 누락된 채 배포되는 사례가 많아졌습니다. 애플리케이션은 매일 변경되는데 점검은 연 1회에 그치는 경우가 많아, 그 사이 새로 추가된 엔드포인트에 접근통제가 빠져 있는 경우를 자주 확인하게 됩니다.
무엇보다 이 유형은 자동화 스캐너로 탐지하기 어렵습니다. 스캐너는 ‘이 요청이 200을 반환하는가’는 알 수 있어도, ‘이 사용자가 이 데이터를 볼 권한이 있는가’는 판단하지 못하기 때문입니다.
데이터가 정상 반환됐는지 여부는 결국 사람만이 판정할 수 있습니다. 그래서 사람이 직접 수행하는 모의해킹에서 그 가치가 가장 선명하게 드러나는 영역이기도 합니다.
2. 현장에서 가장 많이 발견되는 패턴
(1) IDOR (Insecure Direct Object Reference)
가장 흔하고, 임팩트도 큰 유형입니다. 요청 파라미터의 식별자를 변경해 다른 사용자의 데이터에 접근하는 방식입니다.
순차 증가하는 정수 ID가 대표적이지만, UUID를 사용한다고 안전한 것은 아닙니다.
UUID가 응답 어딘가(다른 API의 목록, 이메일, 클라이언트 코드, 캐시 등)에 노출되면 그대로 대입할 수 있기 때문입니다.
핵심은 ‘예측이 가능한가’가 아니라 ‘서버가 소유권을 검증하는가’에 있습니다.
OWASP도 이를 CWE-639(사용자 제어 키를 통한 인가 우회)로 명확히 분류합니다.
식별자는 URL 경로뿐 아니라 쿼리스트링, 요청 본문(JSON), 헤더, 쿠키, multipart 필드에도 숨어 있습니다.
(2) 권한 상승
일반 사용자가 관리자 기능을 호출하는 경우입니다. 화면(UI)에서는 관리자 메뉴가 보이지 않더라도, API는 그대로 열려 있는 사례가 많습니다.
프론트엔드에서 버튼만 숨기고 백엔드 인가 검증을 누락한 전형적인 사례입니다.
요청 본문에 isAdmin, role 같은 필드를 끼워 넣거나(Mass Assignment), JWT·쿠키·히든 필드를 변조해 권한을 올리는 시도가 여기 해당하며, 이런 메타데이터 조작은 2025년판에서 접근통제 결함으로 명시됐습니다.
(3) 권한 간 이동 및 메서드별 인가 누락
같은 권한 사용자 간 이동, 하위 권한에서 상위 권한으로의 이동 외에도, 특정 HTTP 메서드에만 인가가 빠지는 경우가 있습니다.
GET은 막았지만 PUT·DELETE·PATCH는 막지 않은 사례가 대표적이므로, 메서드별로 반드시 구분해 점검해야 합니다.
(4) 중요 페이지의 비인증 접근
인증이 필요한 페이지나 관리자 전용 URL을 비로그인 상태로 직접 요청해 접근되는 경우입니다.
curl 한 줄이면 프론트엔드의 화면 제어를 그대로 우회할 수 있습니다.
3. 점검 방법
접근통제 점검의 핵심은 최소 2개 이상의 계정입니다. 권한이 서로 다른 계정을 준비한 뒤 세션을 교차하며 검증합니다.
(예: A : 일반 사용자 / B : 관리자)
유의사항 : 응답 코드만 보지 말고 응답 본문까지 확인해야 합니다. 200 OK라도 빈 데이터인지 실제 타인의 데이터인지에 따라 판정이 갈리며, 이를 통해 오탐·미탐을 줄일 수 있습니다.
심화 취약점 사항 확인
: 단순 조회 수준인지, 개인정보(주민등록번호·연락처·결제정보)까지 노출되는지 확인합니다.
: 특정 1명에 한정되는지, 전체 사용자 접근 및 확인이 가능한지 확인합니다 (자동화로 대량 수집이 가능하면 위험도 상향).
: 읽기만 가능한지, 수정·삭제까지 가능한지 확인합니다.
: 로그인 없이 접근 및 사용이 가능한지 확인 합니다.
4. 조치 방안
핵심 요약
※ 참고 자료
· OWASP Top 10:2025 — A01: Broken Access Control
· OWASP Web Security Testing Guide — Authorization Testing
· OWASP Cheat Sheet — Authorization
· OWASP Application Security Verification Standard — V8 Authorization
· MITRE CWE-639 — Authorization Bypass Through User-Controlled Key
신원상 | sws@cela.kr