Secure API Design: Replace Sequential IDs with UUIDs

순차적 ID 대신 암호화된 키 사용하기

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

보안

대상자

  • 대상: API 개발자, 웹 애플리케이션 개발자, 보안 전문가
  • 난이도: 중급~고급 (보안 취약점 분석 및 리팩토링 경험이 필요)

핵심 요약

  • UUIDs 사용으로 IDOR 공격 예방 → sequential IDs 대체
  • 예측 가능한 URL데이터 크롤링 위험 감소 → UUID 적용
  • 내부 ID 비공개외부 UUID 공개캡슐화 강화

섹션별 세부 요약

1. IDOR 취약점과 예측 가능한 ID 문제

  • IDOR (Insecure Direct Object Reference) 공격: 순차적 ID로 인한 객체 직접 참조 가능성 증가
  • Predictable URLs: URL에 포함된 순차적 ID로 인한 사용자 정보 유출 위험
  • Data Scraping: 자동화된 크롤러가 순차적 ID를 활용한 데이터 수집 가능성 증가

2. 리팩토링 단계

  • Step 1: API, URL, UI에서 사용 중인 sequential IDs 식별
  • Step 2: 데이터 이전 또는 생성 시 UUIDs 생성 (예: generate_uuid() 함수 사용)
  • Step 3: 외부 인터페이스에서 sequential IDsUUIDs로 대체
  • Step 4: 내부 시스템에서 UUIDoriginal ID 매핑 (프라이버트 룩업 테이블 또는 서비스 사용)
  • Step 5: 모든 서비스 및 데이터베이스에서 UUIDs 일관성 유지

3. 리팩토링의 이점

  • Encapsulation 개선: 내부 ID 비공개 → 시스템 구조 유출 방지
  • API 설계 정리: 명시적 매핑을 통한 명확한 인터페이스 설계
  • RESTful API마이크로서비스에서 효과적 적용 가능
  • 404 리소스에 대한 Rate Limiting 적용 가능 (공격 시 시도 제한)

4. 추가 고려사항

  • Dual Access 유지: 리팩토링 중 UUIDID 동시 접근 허용 (단계적 업데이트 지원)
  • Client-Facing Integration 업데이트: 일부 시스템이 수치 ID에 의존할 수 있음

결론

  • UUIDs 적용을 통해 IDOR 취약점 방지 및 데이터 유출 위험 최소화 → 보안 강화
  • 리팩토링 시 단계적 접근테스트 수행 필수 → 백워드 호환성 유지
  • UUID 일관성 유지 및 내부 매핑 테이블 사용 → 시스템 확장성과 안정성 향상