Meal API Troubleshooting(API 보안 강화)

🥗 Meal API 구현 중 발생한 설계 이슈 및 해결 (Troubleshooting)

1. IDOR(Insecure Direct Object Reference) 취약점 방지

• 문제 상황: 특정 식단 조회(GET /meals/:id) 시, 식단의 id값(UUID)만으로 조회할 경우 다른 사용자의 UUID를 추측하거나 입수하여 타인의 식단 기록을 열람할 위험이 있었습니다.
• 해결 방법: 서비스 계층에서 조회 쿼리 작성 시, id와 함께 JWT에서 추출한 userId를 복합 조건으로 사용하도록 수정했습니다.
• 코드 변화:
   

  // 변경 전: 단순 ID 조회
  const meal = await this.prisma.meal.findUnique({ where: { id } });
  
  // 변경 후: 소유권 검증 포함
  const meal = await this.prisma.meal.findFirst({
    where: { id, userId },
  });
  

• 결과: 데이터 소유권이 명확히 격리되어 보안성이 향상되었습니다.

2. 403 Forbidden vs 404 Not Found: 보안적 선택

• 문제 상황: 타인의 식단에 접근하려 할 때 403(권한 없음)을 반환하면, 공격자에게 "이 ID의 데이터가 실제로 존재한다"는 정보를 노출하게 됩니다.
• 해결 방법: 보안성 강화를 위해 데이터가 존재하더라도 본인의 것이 아니면 일관되게 **404 Not Found**를 반환하도록 설계했습니다.
• 교훈: 'Security through Obscurity(은닉을 통한 보안)'를 통해 리소스 존재 여부 자체를 숨기는 것이 더 안전하다는 것을 배웠습니다.

3. 유연한 수정을 위한 PATCH 메서드와 DTO 설계

• 문제 상황: 식단 수정 기능 구현 시, 모든 필드를 보내야 하는 PUT 방식은 클라이언트 측에 불필요한 데이터 전송 부하를 줍니다.
• 해결 방법: PartialType을 활용한 UpdateMealDto를 생성하여, 클라이언트가 수정을 원하는 필드만 선택적으로 보낼 수 있도록 PATCH 메서드를 적용했습니다.
• 기술 포인트: class-validator의 @IsOptional() 데코레이터를 사용하여 타입 안정성을 유지하면서도 유연한 데이터 수신을 가능케 했습니다.