학습 목표
- 누구인지 확인한 뒤 무엇을 할 수 있는지 다시 확인합니다.
- 모든 자원과 행동, 직접 DB 접근과 서버 API를 함께 보호합니다.
- 실습의 완료 조건과 실패 시 회복 방법을 직접 확인합니다.
사전 지식
인증과 권한을 안전하게 나누기에서 기본 용어를 먼저 확인하세요. 예시는 기존 운영 서비스를 자동으로 바꾸는 설정이 아니라 별도 연습 화면·프로젝트에 적용하는 출발점입니다.
개념 이해
로그인 여부와 수정 권한은 다릅니다. URL이나 요청의 ID를 바꿔도 다른 사람의 데이터를 읽거나 수정할 수 없도록 자원마다 서버에서 권한을 확인해야 합니다.
입력 UID와 검증된 사용자 구분
요청 본문에 들어 있는 userId나 isAdmin은 사용자가 바꿀 수 있습니다. 검증한 인증 토큰의 UID를 기준으로 소유자를 판정합니다. 토큰 형식만 읽는 디코딩과 서명·발급자·대상·만료 확인을 포함한 검증은 다르며 신뢰할 수 있는 서버 SDK를 사용합니다.
자원별로 허용표 만들기
게시글 읽기·생성·수정·삭제와 관리자 처리의 허용 대상을 나눕니다. 생성 시 소유자를 토큰에서 정하고 수정으로 소유자가 바뀌지 못하게 합니다. 댓글·파일·하위 문서도 상위 자원의 소유권·공개 범위와 맞춰 검사합니다. 기본은 거절하고 필요한 경우만 허용합니다.
서버 SDK와 DB 정책의 차이
서버 관리자 SDK는 일반 클라이언트 Rules를 우회할 수 있으므로 API 자체의 권한 검사가 필요합니다. 클라이언트가 DB에 직접 접근하는 기능에는 Rules나 RLS도 별도로 둡니다. 버튼 숨기기·예측하기 힘든 ID·App Check는 소유권 검사를 대신하지 않습니다.
역할 변경과 삭제의 경쟁 상태
권한이 바뀌거나 탈퇴하는 중에는 이전 결과를 계속 쓰지 않도록 처리합니다. 중요한 변경은 트랜잭션 안에서 현재 소유권·잠금 상태를 확인합니다. 계정별 비공개 응답을 공유 CDN 캐시에 넣지 않고 오류 메시지로 타인의 비공개 자원 존재가 새지 않게 설계합니다.
실제 사용 사례
프로필 편집 API가 본문의 uid를 받아 그대로 저장하면 다른 회원 ID를 넣는 공격이 가능합니다. 경로의 대상과 검증된 토큰의 사용자를 비교하고 관리자 예외가 있다면 서버가 검증한 역할만 사용합니다.
단계별 실습
- 자원과 행동별 공개·소유자·관리자 허용표를 적으세요.
- 요청의 ID·역할을 어디에서 신뢰하는지 추적하세요.
- 생성·수정·삭제·하위 자원에 같은 경계가 적용되는지 확인하세요.
- 서로 다른 연습 계정 A/B로 ID를 바꾼 요청이 거절되는지 확인하세요.
- 탈퇴 중·권한 회수·공유 캐시에서도 같은 보호가 유지되는지 검토하세요.
코드와 프롬프트
아래 예시는 프로젝트 설계·검토 문서에 적용하는 예시입니다. 이벤트·서버 검증·운영 설정 전체를 대신하지 않습니다. 기존 코드와 설치 버전을 먼저 확인하세요.
요청 → 서버에서 토큰 검증 → 자원 조회
→ 검증된 UID와 자원 소유자 비교
→ 허용 필드·입력·계정 상태 확인
→ 필요한 경우 트랜잭션에서 다시 확인
→ 저장 후 비공개 응답 반환대괄호를 실제 상황으로 바꿔 요청하세요. 비밀 값과 개인정보 원문은 넣지 마세요.
[API와 자원]의 읽기·생성·수정·삭제 권한표를 만들고 서버 토큰 검증·소유자 불변·하위 자원·관리자 SDK 우회·탈퇴 잠금을 점검해줘. 타인 ID·위조 역할·만료 토큰은 별도 연습 환경에서만 확인해줘.자주 발생하는 문제와 해결
| 문제 | 해결과 확인 |
|---|---|
| 로그인하면 모든 문서를 수정할 수 있다 | 자원 소유자와 행동별 권한을 추가합니다. |
| Rules가 있으니 Admin API도 안전하다고 생각한다 | 관리자 SDK를 쓰는 서버 경로에 인증과 권한 검사를 둡니다. |
핵심 요약
- 누구인지 확인한 뒤 무엇을 할 수 있는지 다시 확인합니다.
- 모든 자원과 행동, 직접 DB 접근과 서버 API를 함께 보호합니다.
완료 확인
참고자료
확인 기준일: 2026-10-20. 기능·제품 요금·법령은 변경될 수 있으므로 적용 시 공식 문서와 현재 시행일·설치 버전을 다시 확인하세요.