위험도 · 치명적

API 인가 우회 (IDOR·BOLA)

요청에 담긴 ?userId= 값만 믿고 진짜 주인인지 확인하지 않으면, 숫자만 바꿔 남의 데이터를 볼 수 있습니다.

이게 무슨 문제인가요?

많은 앱이 "누가 로그인했는지"(인증)는 확인하면서 "이 데이터에 접근할 권한이 있는지"(인가)는 빠뜨립니다. 특히 API 가 ?userId=123처럼 URL 파라미터나 요청 본문으로 "누구의 데이터인지"를 받고, 그 값이 정말 로그인한 본인인지 서버에서 검증하지 않으면, 값을 다른 번호로 바꾸는 것만으로 남의 데이터에 접근하게 됩니다. 흔히 IDOR(접근 권한 우회) 또는 BOLA 라고 부르며, OWASP API 보안 위험 1위입니다.

왜 위험한가요?

공격자(때로는 로그인조차 안 한 사용자)가 ID 값을 1씩 바꿔가며 전체 고객의 데이터를 순서대로 긁어올 수 있습니다. 조회뿐 아니라 수정·삭제 API 에도 같은 문제가 있으면 남의 데이터를 바꾸거나 지울 수 있습니다. 대량 개인정보 유출로 곧장 이어지는 유형입니다.

내 앱도 해당되나요?

로그인한 상태에서 앱이 보내는 API 요청에 ?userId=·?id= 같은 식별자가 있는지 보고, 그 값을 내가 가진 다른 테스트 계정의 값으로 바꿨을 때 데이터가 나오는지 확인합니다. (자가 점검은 반드시 본인 소유 계정 두 개로만 하고, 타인의 데이터에 접근을 시도하지 마세요.)

어떻게 고치나요?

1
데이터 주인을 세션에서 도출
누구의 데이터인지는 클라이언트가 보낸 값이 아니라 서버가 검증한 세션/토큰에서 가져옵니다. 요청에 담긴 userId는 신뢰하지 않습니다.
2
모든 조회·수정에 소유권 검사
데이터를 다룰 때마다 "이 자원이 현재 로그인 사용자 것인가"를 확인합니다. 예: 쿼리에 where user_id = 세션_사용자_id 조건을 강제합니다.
3
Supabase 면 RLS 로 강제
DB 레벨에서 auth.uid() = user_id 같은 RLS 정책으로 막으면, 애플리케이션 코드가 실수해도 다른 사람 데이터가 새지 않습니다.
4
인증 미들웨어를 모든 API 에 적용
/api 전 구간에 인증·인가 미들웨어가 실제로 적용되는지 확인합니다. 경로 매칭이 빠져 일부 API 가 무방비인 경우가 흔합니다.
5
다른 계정으로 재점검
수정 후 다른 계정의 ID 로 요청했을 때 403(거부) 또는 빈 결과가 돌아오는지 확인합니다.

자주 묻는 질문

로그인은 잘 되는데 왜 위험한가요?

로그인(인증)과 권한 검사(인가)는 다릅니다. 로그인이 됐어도, 서버가 "이 데이터가 이 사람 것인지"를 확인하지 않으면 로그인한 사용자가 남의 데이터에 접근할 수 있습니다.

IDOR 와 BOLA 는 같은 건가요?

거의 같은 의미로 쓰입니다. IDOR(Insecure Direct Object Reference)는 식별자를 바꿔 다른 자원에 접근하는 문제이고, BOLA(Broken Object Level Authorization)는 그 원인을 가리키는 OWASP 의 API 보안 용어입니다.

Supabase RLS 만 켜면 막히나요?

DB 접근을 RLS 로 막으면 큰 도움이 되지만, 자체 백엔드 API 가 service_role이나 우회 경로로 데이터를 내려준다면 그 경로에도 소유권 검사가 따로 필요합니다.