서버에서 소유권을 도출하세요
레코드 ID는 무언가를 식별하지만 누가 읽을 수 있는지 증명하지 않습니다. supastack은 사용자 소유 레코드를 workspaceId로 범위 지정합니다. 서버는 인증된 사용자의 워크스페이스를 해석하고 레코드를 읽거나 바꿀 때 그 범위를 포함합니다.
브라우저가 보낸 워크스페이스 ID를 소유권 증명으로 취급하지 마세요. 브라우저는 액션을 요청할 수 있지만 신뢰된 서버 컨텍스트가 누구의 액션인지를 확립해야 합니다. 이 규칙은 작업 상태, 저장된 프로바이더 구성, 사용량 레코드, 모든 제품 소유 리소스에 유지되어야 합니다. 레이아웃과 컴포넌트는 렌더링할 것을 필터링할 수 있지만 렌더링은 인가가 아닙니다 — 검사는 레코드가 실제로 읽히거나 쓰이는 곳에 속합니다.
이 포스트의 나머지는 모두 그 규칙에서 나옵니다: 소유권은 요청되는 것이 아니라 도출됩니다. 클라이언트가 보낸 workspaceId가 어딘가에서 신뢰되는 순간, 다른 모든 검사는 장식이 됩니다. 인증 포스트는 이 경계의 상류에서 세션 자체가 어떻게 확립되는지 다룹니다.
멤버십도 경계의 일부입니다
범위 지정은 레코드가 어느 워크스페이스에 속하는지를 답하고, 멤버십은 이 사용자가 그 워크스페이스에 속하는지를 답합니다. 둘 다 서버에서 해석하세요. supastack은 소유자, 관리자, 멤버 역할로 개인 및 조직 워크스페이스를 모델링합니다 — 워크스페이스 가이드가 그 모델을 문서화합니다.
역할은 두 번째 축을 더합니다: 멤버는 관리자만 바꿀 수 있는 것을 읽을 수 있습니다. 두 검사를 구분해 두세요 — “이 워크스페이스에 속하는가”와 “이 작업을 수행할 수 있는가” — 그래야 강등이나 제거가 다른 모든 것과 같은 경계에서 효력을 가집니다. 초대와 제거는 관리자의 나중 생각이 아니라 같은 라이프사이클의 일부입니다.
멤버십 변경도 즉시 효력을 가져야 합니다. 제거된 멤버의 다음 요청은 캐시된 토큰이 마침 만료될 때가 아니라 경계에서 실패해야 합니다 — 이것이 검사가 이전에 발급된 자격 증명 안이 아니라 레코드가 읽히는 곳에 있는 또 다른 이유입니다.
액세스를 부여하지 않으면서 복구를 유용하게 만드세요
작업 URL은 사용자가 새로고침 후 돌아올 수 있게 합니다. 작업에 대한 참조를 보존하기 때문에 유용합니다. 인증된 API는 상태나 결과를 반환하기 전에 요청된 작업이 현재 워크스페이스에 속하는지 여전히 확인해야 합니다.
같은 원칙이 제출 복구에 적용됩니다. 멱등성 키는 반복된 요청을 식별하고 중복 작업을 방지하는 데 도움이 됩니다. 세션도 액세스 토큰도 아닙니다. 저장된 제출을 재시도하려면 여전히 인증, 워크스페이스 소유권, 적절한 권한이 필요합니다.
편의 경로는 격리가 조용히 침식되는 곳입니다. 합법적인 사용자가 작업을 재개하게 돕는 링크 — 새로고침 후 또는 완료 이메일에서 — 는 다른 요청과 같은 인증된 검사를 통과해야 합니다. 요청-결과 파이프라인은 바로 이 원칙으로 작업 범위 멱등성 키를 사용합니다.
실패해야 하는 요청을 테스트하세요
소유자가 레코드를 가져올 수 있게 하는 테스트는 해피 패스를 증명합니다. 격리를 증명하지는 않습니다. 같은 레코드를 요청하는 두 번째 워크스페이스, 익명 요청, 다른 소유자를 덮어쓰려는 쓰기와 짝지으세요.
지속된 결과만큼 외부 동작도 단언하세요. 거부된 요청은 다른 워크스페이스의 데이터를 변경해서는 안 되며, 오류 응답은 시크릿이나 원시 데이터베이스 세부 정보를 누출해서는 안 됩니다. 이러한 검사는 구현이 바뀔 때 경계를 리뷰된 상태로 유지합니다.
- 두 번째 워크스페이스가 같은 레코드 ID를 요청 — 거부됨.
- 익명 요청이 같은 엔드포인트를 침 — 거부됨.
- 워크스페이스에서 제거된 멤버가 재시도 — 거부됨.
- 다른 소유자나 워크스페이스를 지목하는 쓰기 — 거부됨, 아무것도 변경되지 않음.
- 오류 응답은 일반적으로 유지 — 시크릿 없음, 스키마 세부 없음.
규칙을 제품으로 가져가세요
새 제품 테이블을 추가할 때 화면을 만들기 전에 소유권을 결정하세요. 영속화 모델에 workspaceId를 포함하고, 기존 서버 경계를 통해 워크스페이스를 해석하고, 목록과 상세 작업 모두에서 그 컨텍스트를 사용하세요.
백그라운드 워커도 같은 주의가 필요합니다. 큐에 넣은 작업은 올바른 레코드를 로드할 만큼 충분한 신뢰 컨텍스트를 가져야 하며 프로바이더 자격 증명은 서버에 남아야 합니다. ID만으로 행을 로드하는 예약 작업도 여전히 경계 안에 있습니다. 일관된 소유권 규칙이 라우트별 예외 모음보다 유지하기 쉽습니다.
API 표면도 같은 경계에 속합니다. 워크스페이스 API 키와 서명된 아웃바운드 웹훅은 워크스페이스의 범위를 함께 나릅니다 — 키는 테넌트를 가로질러 읽는 방법이 되어서는 안 되고, 웹훅 페이로드는 이웃의 레코드를 담아서는 안 됩니다. API 모듈 가이드가 그 표면의 형태를 다룹니다.
워크스페이스 격리에 관한 흔한 질문
멀티테넌트 격리는 모든 프로젝트에서 같은 몇 가지 질문을 불러일으킵니다. 일찍 정리할 가치가 있는 것은 이것들입니다.
- 애플리케이션 수준 범위 지정으로 충분한가요, 행 수준 보안이 필요한가요? — 모든 읽기와 쓰기에 대한 서버 강제 범위 지정은 대부분의 SaaS 위협 모델을 커버합니다. 데이터베이스 RLS는 심층 방어를 더하지만 경계 검사를 대체하지는 않습니다 — 워커와 API 키도 같은 규칙이 필요합니다.
- 워크스페이스 간 공유는 어떻게 해야 하나요? — 범위를 약화하는 대신 명시적으로 모델링하세요 — 초대, 멤버십 행. “링크를 가진 누구나”는 사고가 아니라 자체 검사를 가진 설계된 기능이어야 합니다.
- 멀티테넌트 앱에서 무엇이 먼저 깨지나요? — 편의 경로: 복구 링크, 관리 도구, ID만으로 레코드를 로드하는 백그라운드 워커. 정상 범위를 거치지 않고 레코드를 건드리는 모든 코드 경로를 감사하세요.
- 기존 테이블에 범위 지정을 어떻게 추가하나요? —
workspaceId를 추가하고, 채우고, 읽기와 쓰기에서 강제한 뒤 UI를 건드리세요. 경계가 가정이 아니라 증명되도록 네거티브 테스트를 먼저 출시하세요. - 페이지가 보호되면 서버 액션에도 검사가 필요한가요? — 네. 페이지 가드는 화면을 숨길 뿐 작업을 인가하지 않습니다. 모든 액션은 세션과 워크스페이스를 독립적으로 해석합니다.