홈 / 가이드 / Firebase 보안 규칙 체크리스트

Firebase 보안 규칙 점검 체크리스트

Firestore·Storage 규칙이 ‘모두 허용’으로 남아 있으면 누구나 회원 데이터를 읽고 지울 수 있습니다. 바로 확인할 수 있는 점검 항목과 고치는 순서를 정리했습니다.

앱몬스터 · 작성 2026-09-16

핵심 답변

Firebase 콘솔의 Firestore·Storage 규칙에 allow read, write: if true; 또는 기한이 지난 테스트 모드 규칙이 남아 있다면 데이터가 외부에 열려 있는 상태입니다. 기본 거부 규칙을 두고, 컬렉션별로 로그인 사용자·본인 문서만 허용하도록 바꾸는 것이 첫 조치입니다.

개발 몰라도 확인: Firebase 외에 계정·도메인·백업까지 한 번에 보려면 → 무료 「사장님용 웹·앱 보안 체크리스트 30」 PDF

가장 위험한 규칙 3가지

// 1. 전부 허용
allow read, write: if true;

// 2. 로그인만 하면 누구 데이터든 허용
allow read, write: if request.auth != null;

// 3. 테스트 모드 기한 규칙 (기한이 지나면 전부 거부 → 서비스 장애)
allow read, write: if request.time < timestamp.date(2026, 1, 1);

2번은 안전해 보이지만, 익명 로그인이 켜져 있으면 사실상 누구나 로그인할 수 있어 1번과 다르지 않습니다.

열린 규칙 vs 안전한 규칙

같은 데이터, 다른 규칙

열려 있는 규칙 (위험)

  • 전부 허용 — 누구나 읽고 삭제
  • 로그인만 하면 남의 데이터도 접근
  • 기한 지난 테스트 규칙 방치
  • 관리자 판별을 앱 화면에만 의존

좁힌 규칙 (안전)

  • 기본 거부 후 필요한 경로만 허용
  • 본인 문서만: uid == userId
  • Storage는 소유자·크기·형식 제한
  • 관리자는 Custom Claims로 서버 판별
핵심은 ‘기본 거부를 깔고 필요한 곳만 연다’입니다. 반대 방향(다 열고 막기)은 늘 구멍이 남습니다.

점검 체크리스트 10

  1. Firestore 규칙 맨 아래에 기본 거부(match /{document=**} { allow read, write: if false; })가 있는가
  2. 사용자 문서는 request.auth.uid == userId로 본인만 쓰게 되어 있는가
  3. 관리자 권한을 클라이언트 필드가 아니라 Custom Claims 등 서버 쪽으로 판정하는가
  4. Storage 규칙에 경로별 소유자 확인과 파일 크기·형식 제한이 있는가
  5. 한 Firebase 프로젝트를 여러 앱이 같이 쓴다면 컬렉션 접두사별 규칙이 분리되어 있는가
  6. 서비스 계정 키(JSON)나 서버용 API 키가 앱 코드·공개 저장소에 들어가 있지 않은가
  7. App Check로 앱이 아닌 곳의 요청을 줄이고 있는가
  8. Cloud Functions의 호출 권한과 입력 검증이 있는가
  9. 연락처·주소 등 개인정보를 필요한 경우 암호화해 저장하는가
  10. 규칙 변경이 에뮬레이터 테스트를 거쳐 배포되는가

안전하게 고치는 순서

규칙을 좁히는 4단계
1
현재 규칙 백업지금 규칙을 복사해 두고 시작. 문제가 생기면 되돌립니다.
2
기본 거부 깔기재귀 와일드카드로 전부 거부한 뒤, 필요한 경로만 하나씩 엽니다.
3
에뮬레이터로 시험주요 화면의 읽기·쓰기를 먼저 테스트. 권한 오류를 미리 잡습니다.
4
배포 후 모니터링배포 직후 권한 오류 로그를 확인하며 누락된 허용을 보완합니다.
규칙을 갑자기 좁히면 기존 기능이 권한 오류를 냅니다. 반드시 에뮬레이터 테스트를 거쳐 배포하세요.

여러 앱이 한 프로젝트를 쓰는 경우

앱몬스터도 한 Firebase 프로젝트에서 여러 서비스를 컬렉션 접두사로 나눠 운영하며, 통합 규칙 파일 하나에 앱별 규칙과 기본 거부를 함께 관리합니다. 재귀 와일드카드 기본 거부는 새로 만든 하위 컬렉션까지 막기 때문에, 기능을 추가할 때마다 규칙을 같이 갱신해야 합니다. 자세한 분리 방법은 Firebase 프로젝트 공유를 참고하세요.

자주 묻는 질문

규칙을 바꾸면 앱이 멈추지 않나요?

허용 범위를 좁히면 기존 기능이 권한 오류를 낼 수 있습니다. Firebase 에뮬레이터나 규칙 플레이그라운드로 주요 화면의 읽기·쓰기를 먼저 시험한 뒤 배포하세요.

Firebase 웹 API 키가 노출되면 위험한가요?

웹 설정의 apiKey는 식별용이라 공개 자체는 정상입니다. 위험한 것은 보안 규칙이 열려 있는 상태와, 서비스 계정 키·서버용 비밀키 노출입니다.

기본 거부를 깔면 새 기능이 다 막히지 않나요?

재귀 와일드카드 기본 거부는 새 하위 컬렉션까지 막습니다. 그래서 기능을 추가할 때마다 그 경로의 허용 규칙을 함께 추가해야 합니다. 번거롭지만 이것이 데이터가 새지 않게 하는 안전한 방향입니다.

점검을 맡기면 무엇을 받나요?

앱몬스터 보안 점검은 규칙·권한·키 노출·백업·SSL 항목을 확인해 위험도별 리포트와 긴급 조치를 제공합니다.

무료 점검부터 시작하세요

지금 규칙이 열려 있는지 모르겠다면, 프로젝트 구성만 알려주셔도 규칙·권한·키 노출 위험을 먼저 진단해 드립니다.

무료 점검 문의 → appmonster.co.kr

문의: appmonster.kr@gmail.com

함께 보기: 보안 규칙 실수 TOP 5 · Firebase 프로젝트 공유 · API키 노출