암호화 유틸리티 추가

[ckdals4600]

이슈 배경

• API로 id 값을 전달할 때 평문 노출 방지를 위한 암호화 필요
• 응답 DTO, 요청 파라미터, URL(Path/Query)에서 일관된 방식으로 사용 가능한 유틸리티 추가

이슈 내용

• 공통 모듈에 EncryptionUtil 추가
  • 역할
    • URL-safe Base64 기반 암호화 및 복호화 메소드 제공
  • String encrypt(String plain) : 암호화 메소드
  • String decrypt(String cipher) : 복호화 메소드
• 알고리즘: 대칭키 기반 (예: AES/GCM/NoPadding, 256bit)
  • IV(Nonce) 무작위 생성, GCM 태그 포함
  • 키 로딩: 우선순위 ENV → application.yml (프로필별 분리)
  • 결과 포맷: version.iv.ciphertext.tag 를 URL-safe Base64로 인코딩
• 적용 범위
  • 응답 DTO의 id 필드 암호화
  • 요청 파라미터/경로의 암호화된 id 복호화 처리

참고 자료

No response

[ckdals4600]

@Goder-0 @minibr
암호화 유틸에 대한 의견 남깁니다!

DB에 저장된 모든 Entity의 id는 외부로 전달될 때 반드시 암호화해야 한다고 생각합니다
조회와 관련된 서비스의 경우 왠만해서는 id값이 외부로 전달된다고 생각하며

저희 서비스에서 예시를 찾아보면,

• chat 테이블: 채팅 평가(예: 좋아요/싫어요, 신고 등) 전송 시 chat id가 오가게 될 가능성이 높음
• member(user) 관련 데이터: 사용자 식별 값 역시 요청/응답 간 주고받을 일이 많음
  등의 서비스에서 id이 유출된다고 생각합니다.

따라서 id가 직접 노출되지 않도록 암호화 유틸리티를 전역적으로 적용하는 게 안전하다고 봅니다.
이렇게 하면 보안적으로 노출 위험을 줄이고, API 응답에서도 일관성 있는 규칙을 유지할 수 있을 것 같습니다.

그리고 추후에 암호화 로직을 따로 추가하는 것보다, 지금 단계에서 암호화 유틸을 먼저 도입해두고 작업을 진행하는 것이 더 효율적이라고 생각합니다.

[Goder-0]

제 의견 공유를 위해 GPT와의 대화를 공유합니다.

🔍 실제 업계에서 흔한 패턴

1. 그냥 DB ID(Long, UUID 등) 노출
   • 가장 흔한 케이스입니다.
   • Twitter, GitHub, 대부분의 REST API가 그냥 숫자 ID나 UUID를 그대로 반환해요.
   • 이유: 단순하고, 성능 오버헤드 없음, 디버깅이 쉬움.
   • 대신 DB 시퀀스 ID를 그대로 노출하면 "다음 ID가 뭘까?" 같은 추측은 가능해요.
2. UUID / ULID 사용
   • 시퀀스 ID 노출을 꺼리는 경우, auto-increment 대신 랜덤성 있는 식별자(UUID/ULID) 를 사용.
   • 클라이언트 입장에서는 유추가 어렵고, 추가적인 암호화 로직이 필요 없음.
   • 다만 PK 크기가 커지고 인덱스 효율은 조금 떨어질 수 있어요.
3. Hashids / Base62 Encoding / Custom Token
   • 일부 서비스에서는 숫자 ID → 사람이 보기 어려운 문자열로 변환 해서 전달.
   • 예: YouTube 영상 ID(dQw4w9WgXcQ) 같은 것.
   • 이건 보안 목적보다는 가독성 + URL 친화성이 큼.
   • 완전한 보안은 아님 (디코딩 가능).
4. 진짜 암호화(Tokenization)
   • 민감 데이터(예: 주민번호, 결제 카드 ID)일 경우는 토큰화나 암호화 를 거쳐서 반환.
   • 하지만 일반적인 "DB PK 값"은 그렇게까지 안 함.

위와 같은 사유로 저는 암호화가 반드시 필요하다고 생각하지 않습니다.
혹시 어떻게 생각하시나요?

[ckdals4600]

제 의견 공유를 위해 GPT와의 대화를 공유합니다.

🔍 실제 업계에서 흔한 패턴

1. 그냥 DB ID(Long, UUID 등) 노출

   • 가장 흔한 케이스입니다.
   • Twitter, GitHub, 대부분의 REST API가 그냥 숫자 ID나 UUID를 그대로 반환해요.
   • 이유: 단순하고, 성능 오버헤드 없음, 디버깅이 쉬움.
   • 대신 DB 시퀀스 ID를 그대로 노출하면 "다음 ID가 뭘까?" 같은 추측은 가능해요.

2. UUID / ULID 사용

   • 시퀀스 ID 노출을 꺼리는 경우, auto-increment 대신 랜덤성 있는 식별자(UUID/ULID) 를 사용.
   • 클라이언트 입장에서는 유추가 어렵고, 추가적인 암호화 로직이 필요 없음.
   • 다만 PK 크기가 커지고 인덱스 효율은 조금 떨어질 수 있어요.

3. Hashids / Base62 Encoding / Custom Token

   • 일부 서비스에서는 숫자 ID → 사람이 보기 어려운 문자열로 변환 해서 전달.
   • 예: YouTube 영상 ID(dQw4w9WgXcQ) 같은 것.
   • 이건 보안 목적보다는 가독성 + URL 친화성이 큼.
   • 완전한 보안은 아님 (디코딩 가능).

4. 진짜 암호화(Tokenization)

   • 민감 데이터(예: 주민번호, 결제 카드 ID)일 경우는 토큰화나 암호화 를 거쳐서 반환.
   • 하지만 일반적인 "DB PK 값"은 그렇게까지 안 함.

위와 같은 사유로 저는 암호화가 반드시 필요하다고 생각하지 않습니다. 혹시 어떻게 생각하시나요?

공유해 주신 내용처럼 일반적인 리소스 조회에서는 ID 노출이 흔한 패턴이라는 점에 동의합니다.

하지만 현재 구현된 채팅 소켓의 경우, chatId를 통해 바로 접근이 가능한 구조입니다. 만약 이 ID가 평문으로 노출되어 유추가 가능해진다면, 악의적인 사용자가 ID를 변조하여 타인의 채팅방에 무단으로 접속하거나 내용을 훔쳐보는 위험성인 IDOR 취약점이 존재할 것입니다.

따라서 채팅과 같이 프라이버시가 중요한 기능에 한해서는, 외부에서 ID를 유추할 수 없도록 식별자 암호화 조치가 필수적이라고 생각합니다

이러한 이유로 해당 이슈 작업을 진행하겠습니다!