06 §5.3이 "member.id를 공개 응답에 포함하지 않는다"고 정하면서 드는 이유가 둘인데, 둘 다 성립하지 않거나 문서 스스로와 모순된다. 규칙을 바꾸자는 게 아니라 근거를 고치자는 것이다 — 근거가 부실하면 다음 결정이 그 위에 잘못 쌓인다.
현재 문장
member.id는 공개 응답(타인 조회)에 포함하지 않습니다. 순차 값이므로 노출 시 사용자 열거가 가능해지고, 가입 순번이 신원 추론 단서가 됩니다.
이유 1 — "순차 값이라 사용자 열거가 가능" (성립 안 함)
열거가 위험하려면 그 id를 받는 엔드포인트가 있어야 한다. 없다. API 전체가 collectionId·followId로 설계돼 있고(BD-14 식별자 은닉), memberId를 받는 경로는 계획에도 없다. 42번 회원이 존재한다는 걸 알아도 할 수 있는 게 없다.
같은 절이 스스로와 모순되기도 한다.
Collection id는 발행 시 공개 대상이므로 노출되어도 정책 위반이 아닙니다. 사용자 열거와는 성격이 다릅니다.
collection.id도 똑같이 순차다. "성격이 다르다"고 단언만 하고 왜 다른지는 말하지 않는다. 순차 열거가 문제라면 collection id도 같은 문제여야 한다.
이유 2 — "가입 순번이 신원 추론 단서" (순환)
숫자를 사람에 묶을 수단이 있어야 성립하는데, 그 수단이 바로 이유 1에서 없다고 한 것이다.
남는 진짜 근거 (문서가 안 쓰는 것)
04 §1이 "동일 User의 Collection은 하나의 Shelf로 연결되고 다른 사용자가 조회할 수 있다"고 하므로 작성자별 묶어보기는 의도된 기능이다. memberId를 숨겨도 상관관계 자체는 막지 못한다.
실제 차이는 이것뿐이다.
|
상관관계 범위 |
진입점이 collectionId |
서버가 정해준 만큼만 묶인다 |
공개 응답에 memberId |
클라이언트가 모든 응답을 가로질러 조인할 전역 키를 갖는다 |
즉 "열거·가입순번"이 아니라 "익명 서비스에서 전역 조인 키를 주지 않는다" 가 근거다. 다만 이것도 shelf 탐색이 있는 이상 강한 방어는 아니다.
제안
식별자 은닉이 아니라 접근 통제를 안전 근거로 삼는 방향으로 §5.3을 다시 쓴다.
id 노출 자체는 그 id로 남의 것에 접근할 수 있을 때만 위험하다. 그 통제는 이미 구현·검증돼 있다 — id를 받는 모든 엔드포인트가 소유권을 확인하고 404로 은닉하며(isOwnedBy 9곳), 타인 접근 차단 테스트가 10건이다(otherUsersRecordDetailIsHiddenAs404 등). 거기가 실제 방어선이다.
구체적으로:
- 이유 1·2를 걷어내고, 남는 근거(전역 조인 키를 주지 않는다)를 그것대로 적는다. 강한 방어가 아니라는 점도 함께.
collection.id와 성격이 다른 이유를 실제로 쓰거나, 다르지 않다면 그 문장을 뺀다.- 접근 통제가 실제 방어선임을 명시한다. 그래야 다음 사람이 "id를 숨겼으니 안전하다"로 오해하지 않는다.
왜 지금
Team-PinLog/back #63에서 "공개 조회 경로가 Record 엔티티를 공유해 memberId가 조립 함수까지 닿는다"를 §5.3 근거로 문제 삼았다가, 근거를 따져보니 이 절이 부실해서 지적 자체가 성립하지 않았다. 부실한 근거가 실제로 잘못된 판단을 한 번 만들어낸 사례다.
규칙(진입점을 collectionId로 두는 설계)은 이미 구현돼 있고 바꾸자는 게 아니다. 근거만 고치는 문서 작업이다.
06 §5.3이 "member.id를 공개 응답에 포함하지 않는다"고 정하면서 드는 이유가 둘인데, 둘 다 성립하지 않거나 문서 스스로와 모순된다. 규칙을 바꾸자는 게 아니라 근거를 고치자는 것이다 — 근거가 부실하면 다음 결정이 그 위에 잘못 쌓인다.현재 문장
이유 1 — "순차 값이라 사용자 열거가 가능" (성립 안 함)
열거가 위험하려면 그 id를 받는 엔드포인트가 있어야 한다. 없다. API 전체가
collectionId·followId로 설계돼 있고(BD-14 식별자 은닉),memberId를 받는 경로는 계획에도 없다. 42번 회원이 존재한다는 걸 알아도 할 수 있는 게 없다.같은 절이 스스로와 모순되기도 한다.
collection.id도 똑같이 순차다. "성격이 다르다"고 단언만 하고 왜 다른지는 말하지 않는다. 순차 열거가 문제라면 collection id도 같은 문제여야 한다.이유 2 — "가입 순번이 신원 추론 단서" (순환)
숫자를 사람에 묶을 수단이 있어야 성립하는데, 그 수단이 바로 이유 1에서 없다고 한 것이다.
남는 진짜 근거 (문서가 안 쓰는 것)
04 §1이 "동일 User의 Collection은 하나의 Shelf로 연결되고 다른 사용자가 조회할 수 있다"고 하므로 작성자별 묶어보기는 의도된 기능이다. memberId를 숨겨도 상관관계 자체는 막지 못한다.실제 차이는 이것뿐이다.
collectionIdmemberId즉 "열거·가입순번"이 아니라 "익명 서비스에서 전역 조인 키를 주지 않는다" 가 근거다. 다만 이것도 shelf 탐색이 있는 이상 강한 방어는 아니다.
제안
식별자 은닉이 아니라 접근 통제를 안전 근거로 삼는 방향으로 §5.3을 다시 쓴다.
id 노출 자체는 그 id로 남의 것에 접근할 수 있을 때만 위험하다. 그 통제는 이미 구현·검증돼 있다 — id를 받는 모든 엔드포인트가 소유권을 확인하고 404로 은닉하며(
isOwnedBy9곳), 타인 접근 차단 테스트가 10건이다(otherUsersRecordDetailIsHiddenAs404등). 거기가 실제 방어선이다.구체적으로:
collection.id와 성격이 다른 이유를 실제로 쓰거나, 다르지 않다면 그 문장을 뺀다.왜 지금
Team-PinLog/back#63에서 "공개 조회 경로가Record엔티티를 공유해memberId가 조립 함수까지 닿는다"를 §5.3 근거로 문제 삼았다가, 근거를 따져보니 이 절이 부실해서 지적 자체가 성립하지 않았다. 부실한 근거가 실제로 잘못된 판단을 한 번 만들어낸 사례다.규칙(진입점을 collectionId로 두는 설계)은 이미 구현돼 있고 바꾸자는 게 아니다. 근거만 고치는 문서 작업이다.