IDOR란 무엇인가
IDOR(Insecure Direct Object Reference)는 ‘안전하지 않은 직접 객체 참조’라는 뜻으로, 사용자가 자신의 권한 범위를 벗어난 데이터에 직접 접근할 수 있게 되는 취약점을 말합니다. 예를 들어 게시글이나 주문 내역처럼 각 데이터에 고유 ID가 부여된 시스템에서, 서버가 ‘이 ID의 소유자가 요청자와 같은가’를 확인하지 않으면 발생합니다.
흔한 예시는 URL 파라미터입니다. 내 주문 내역을 보기 위해 GET /orders/1024 로 요청했다고 가정해봅시다. 이때 숫자 1024를 1025로 바꿔서 요청했는데도 서버가 응답을 그대로 내려준다면, 이는 다른 사용자의 주문 정보가 그대로 노출되는 IDOR 취약점입니다. 마치 호텔에서 내 방 카드키로 옆방 문도 열리는 것과 같은 상황이라고 볼 수 있습니다. 문의 번호(객체 ID)는 다르지만, 카드키(인증)만 확인하고 ‘이 방이 진짜 당신 방인지’는 확인하지 않은 셈입니다.
왜 발생하고, 어떻게 악용되는가
IDOR은 대부분 ‘인증(Authentication)’과 ‘인가(Authorization)’를 혼동할 때 생깁니다. 로그인 여부만 확인하고, 로그인한 사용자가 해당 리소스에 접근할 자격이 있는지는 별도로 검증하지 않는 것이 핵심 원인입니다. 특히 아래와 같은 상황에서 자주 발견됩니다.
- DB의 auto increment ID를 그대로 URL이나 API 파라미터에 노출하는 경우
- 프론트엔드에서만 접근 제어를 하고 백엔드 API에서는 별도 검증이 없는 경우
- 관리자 페이지와 일반 사용자 페이지가 같은 API를 공유하면서 권한 분기 처리가 누락된 경우
공격자는 단순히 파라미터의 숫자나 UUID 값을 바꿔가며 요청을 반복하는 것만으로도 다른 사용자의 개인정보, 결제 내역, 첨부파일 등에 접근할 수 있습니다. 별도의 해킹 툴 없이 브라우저 개발자 도구나 curl 명령만으로도 시도할 수 있어 진입장벽이 낮은 편에 속합니다.
실무에서 왜 반드시 막아야 하는가
IDOR은 OWASP Top 10에서도 오랫동안 ‘취약한 접근 제어(Broken Access Control)’ 항목의 대표 사례로 언급될 만큼 흔하고 위험한 취약점입니다. SQL 인젝션처럼 복잡한 기술이 필요 없고, 단순히 요청 값을 바꾸는 것만으로 개인정보 유출이나 데이터 변조로 이어질 수 있기 때문에 실무에서는 다음과 같은 방어 전략을 적용합니다.
- 모든 리소스 접근 시 ‘요청자 = 소유자’ 여부를 서버 단에서 매번 검증
- 추측 가능한 순차 ID 대신 UUID처럼 예측 불가능한 식별자 사용
- API 단위 테스트에 권한 우회 시나리오를 포함시켜 회귀 테스트 수행
결국 IDOR 방어의 핵심은 ‘로그인했다’는 사실과 ‘이 데이터를 볼 자격이 있다’는 사실을 별개로 취급하는 것입니다. 이 원칙만 지켜도 상당수의 심각한 정보 유출 사고를 예방할 수 있습니다.