IDOR: 불안전한 직접 객체 참조 — 가장 흔한 API 취약점

지난 글에서 Broken Access Control의 6가지 유형을 개괄적으로 살펴봤습니다. 그 중에서도 버그바운티에서 가장 자주 보고되고 API 보안에서 가장 흔히 발견되는 IDOR(Insecure Direct Object Reference, 불안전한 직접 객체 참조)를 이번 글에서 집중적으로 분석합니다.

IDOR란?

서버가 사용자 요청의 리소스 식별자(ID)를 받아 DB를 조회할 때, 그 리소스가 요청자의 것인지 검증하지 않으면 IDOR입니다. 공격자는 자신의 리소스 ID를 타인의 ID로 바꾸기만 하면 다른 사람의 데이터를 열람하거나 수정할 수 있습니다.

이름이 가리키듯 “직접 객체 참조”가 문제의 핵심입니다. 사용자가 URL이나 파라미터로 DB 레코드를 직접 지목할 수 있고, 서버가 이를 수동적으로 수용하는 구조입니다.

공격 벡터별 상세

URL 경로 파라미터:

# 계정 1337의 세부 정보
GET /api/users/1337/details

# 1337 대신 다른 ID로 변경
GET /api/users/1338/details  → 타인 정보 노출?
GET /api/users/1/details     → 관리자 정보?

쿼리 파라미터:

# 청구서 조회
GET /invoices?invoice_id=INV-2026-001

# 파라미터 변조
GET /invoices?invoice_id=INV-2025-001  → 작년 청구서?
GET /invoices?user_id=99999            → 타인 청구서?

POST 본문 (API):

// 정상: 본인 계좌에서 이체
{
  "from_account": "ACC-1001",
  "to_account": "ACC-2002",
  "amount": 10000
}

// 공격: from_account를 타인 계좌로 변조
{
  "from_account": "ACC-9999",
  "to_account": "ACC-2002",
  "amount": 10000
}

숨겨진 파라미터: 응답 JSON에서 노출된 필드를 요청 파라미터로 재사용하는 경우도 있습니다.

// 응답에 document_id가 포함된 경우
{
  "id": 42,
  "document_id": 7789,  // 이 필드가 다른 API에서 직접 사용된다면?
  "title": "My Document"
}

// 공격자가 document_id를 변경해 다른 문서 접근 시도
GET /api/documents/7790/download

취약 코드와 안전 코드 비교

# Django REST Framework (취약)
class OrderDetailView(APIView):
    def get(self, request, order_id):
        # ❌ order_id만으로 조회 — 소유자 확인 없음
        order = Order.objects.get(id=order_id)
        return Response(OrderSerializer(order).data)

# Django REST Framework (안전)
class OrderDetailView(APIView):
    permission_classes = [IsAuthenticated]
    
    def get(self, request, order_id):
        # ✅ 현재 인증 사용자 + order_id로 복합 조회
        order = get_object_or_404(Order,
                                  id=order_id,
                                  customer=request.user)
        return Response(OrderSerializer(order).data)

// Node.js Prisma (취약 vs 안전)

// ❌ 취약
async function getDocument(req, res) {
  const doc = await prisma.document.findUnique({
    where: { id: req.params.id }
  });
  res.json(doc);
}

// ✅ 안전 — userId로 범위 제한
async function getDocument(req, res) {
  const doc = await prisma.document.findFirst({
    where: {
      id: req.params.id,
      userId: req.user.id  // 소유자 검증
    }
  });
  if (!doc) return res.status(404).json({ error: 'Not found' });
  res.json(doc);
}

사용자 범위 쿼리 패턴

모든 개별 엔드포인트에서 소유자 검증을 추가하는 대신, 쿼리 레벨에서 현재 사용자 범위를 자동으로 적용하는 패턴이 더 안전합니다.

# Django ORM — 사용자 범위 기본 쿼리셋
class DocumentViewSet(viewsets.ModelViewSet):
    serializer_class = DocumentSerializer
    permission_classes = [IsAuthenticated]

    def get_queryset(self):
        # 모든 조회/수정/삭제가 이 쿼리셋 기준으로 동작
        return Document.objects.filter(owner=self.request.user)

    def perform_create(self, serializer):
        # 생성 시 owner 자동 설정
        serializer.save(owner=self.request.user)

// Spring Data JPA — 메서드 이름으로 소유자 검증
public interface OrderRepository extends JpaRepository<Order, Long> {
    // orderId와 userId 모두 일치하는 경우만 반환
    Optional<Order> findByIdAndUserId(Long id, Long userId);
    
    // 모든 주문 조회도 userId 범위로 제한
    List<Order> findAllByUserId(Long userId);
}

// 서비스 레이어
public Order getOrder(Long orderId, Long currentUserId) {
    return orderRepository.findByIdAndUserId(orderId, currentUserId)
        .orElseThrow(() -> new ResponseStatusException(HttpStatus.NOT_FOUND));
}

간접 참조 매핑

외부에 DB ID를 직접 노출하는 대신 세션 기반 매핑을 사용하는 방법도 있습니다:

# 세션에 사용자별 매핑 저장
def get_document(request, index):
    # URL에는 1, 2, 3 같은 세션 내 인덱스만 노출
    document_ids = request.session.get('accessible_documents', [])
    
    try:
        real_id = document_ids[int(index)]
    except (IndexError, ValueError):
        return HttpResponse(status=404)
    
    document = Document.objects.get(id=real_id)
    return JsonResponse(document.to_dict())

실용적으로는 UUID를 사용하면서 소유자 검증을 병행하는 것이 균형 잡힌 방법입니다.

탐지 자동화

# pytest로 IDOR 자동 테스트
import pytest
from django.test import Client

@pytest.mark.django_db
def test_idor_prevention():
    alice = User.objects.create_user('alice', password='pass')
    bob = User.objects.create_user('bob', password='pass')
    
    # Alice의 문서 생성
    doc = Document.objects.create(title='Secret', owner=alice)
    
    # Bob으로 Alice의 문서 접근 시도
    client = Client()
    client.login(username='bob', password='pass')
    
    response = client.get(f'/api/documents/{doc.id}/')
    
    # 404 또는 403이어야 함
    assert response.status_code in [403, 404]
    
    # 응답 본문에 문서 내용이 없어야 함
    assert 'Secret' not in response.content.decode()

버그바운티에서 IDOR

IDOR는 버그바운티 프로그램에서 가장 흔히 제출되는 취약점 중 하나입니다. 다음 체크리스트로 시스템을 점검합니다:

• 계정 두 개를 만들어 각자의 리소스 ID를 교차해서 접근해본다
• Burp Suite로 트래픽을 캡처해 ID가 노출된 모든 파라미터를 식별한다
• API 응답에 포함된 다른 사용자의 ID를 다른 엔드포인트에서 재사용해본다
• 삭제/수정 작업도 소유자 검증이 적용되는지 확인한다

소유자 검증은 모든 리소스 접근 작업(GET, POST, PUT, PATCH, DELETE)에 빠짐없이 적용되어야 합니다.

---

지난 글: Broken Access Control: 접근 제어 취약점 — OWASP Top 1위

다음 글: Path Traversal: 경로 순회로 서버 파일 탈취하기

읽어주셔서 감사합니다. 😊