기존에는 소설과 회차 엔티티 모두 publicId 라는 api에서 조회 시 사용할 대체 키가 존재하였다.

이는 여러가지를 찾아보다가 PK를 노출하는 것보다는 다른 대체 키를 노출하는 것이 좋다는 글들을 봤기 때문이었다.

하지만 솔직히 이 판단에 대한 제대로 된 근거를 찾지는 못했었고, 혼자서도 여러번 고민을 해봤지만 계속해서 답이 나오지 않아서 일단은 uuid 를 활용해 조회용 대체 키를 따로 두기로 결정했었고, 그렇게 소설 관련 기능들까지 다 구현을 했었다.

하지만 그 후 데이터베이스 설계를 배우며 키에 대해 조금 더 알게 되었고, 이 부분을 다시 고민해보게 되었다.

결론적으로 아직도 고민중이긴 하다. 하지만 일단 현재 상황은 MVP 수준도 안되는 정말 기본적인 기능만 구현 중이므로 모두에게 공개된 리소스는 PK 를 노출하는 것으로 결정하였다. 추후에 좀 더 서비스를 고도화 시킬 때는 다시 고민해볼 예정이다.

공개용 대체 키에 대한 오해

보통 검색을 하거나 자료들을 찾아보면 대체로 아래와 같은 이유때문에 PK 노출보다는 공개용 대체 키를 노출하는게 좋다고 한다.

• PK를 노출한 API에서 인증 / 인가 같은 보안 정책이 부실하면 쉽게 공격당할 수 있다.
• PK는 데이터의 개수를 유추해 그 서비스의 규모를 예측할 수 있게 만든다.
• 순차적으로 증가하는 값은 스팸 댓글을 자동으로 등록하게 하는 것 같은 순차공격에 취약하다.

하지만 이 근거들은 어느정도 반박이 가능하다.

첫번째로 PK 든 UUID 든 인증/인가는 필수로 구현해야 한다. 어떤 경우에도 내부 보안은 철저해야 사고를 막을 수 있다. 권한 체크가 부실하면 IDOR(Insecure Direct Object Reference) 취약점으로 이어진다.

예를 들어 /api/users/123/orders/456 같은 API에서

• 인가 체크가 없으면 456을 457, 458로 바꿔가며 다른 사람의 주문 조회 가능
• UUID를 써도 (/api/users/uuid-123/orders/uuid-456) 인가 체크가 없으면 똑같이 뚫림
• 결국 식별자의 형태가 문제가 아니라 사용자가 이 리소스에 접근 권한이 있는가? 를 체크하는 것이 핵심이다.

하지만, 개발자는 항상 실수를 할 수 있으므로 만약 취약점이 발견된다면 이때는 PK 노출이 조금 위험할 수 도 있다. UUID 같은 랜덤한 값은 모호성을 주어 공격을 어렵게 만들지만, PK는 보통 순차적으로 증가하는 값이라서 취약점만 발견되면 공격은 쉽기 때문이다.

두번째로 데이터 개수를 유추할 수 있다는 문제는 상황에 따라 다르다.