Firebase 보안 규칙 실수 TOP 5 — 앱 데이터가 열려 있는 흔한 원인

왜 이렇게 자주 새나

Firebase는 시작이 쉬워서 급하게 출시한 앱이 많습니다. 그 과정에서 보안 규칙은 “나중에”로 미뤄지고, 그 나중이 오지 않습니다. 아래는 점검에서 반복적으로 마주치는 실수입니다.

1위. 전부 허용이 남아 있다

allow read, write: if true;

테스트하려고 열어둔 규칙이 그대로 운영에 올라갑니다. 누구나 앱의 모든 데이터를 읽고 지울 수 있는 상태입니다.

2위. 로그인만 하면 다 된다

allow read, write: if request.auth != null;

안전해 보이지만, 익명 로그인이 켜져 있으면 사실상 누구나 로그인할 수 있어 1위와 다르지 않습니다. request.auth.uid == userId처럼 본인 문서만 허용해야 합니다.

3위. 관리자 판별을 앱 화면에만 맡긴다

관리자 버튼을 화면에서 숨기기만 하고 서버 규칙은 열어두면, 요청을 직접 보내는 방식으로 관리자 기능이 뚫립니다. 관리자 여부는 Custom Claims 등 서버 쪽에서 판별해야 합니다.

4위. 한 프로젝트를 여러 앱이 공유하는데 규칙이 안 나뉜다

비용을 아끼려고 한 Firebase 프로젝트를 여러 서비스가 컬렉션 접두사로 나눠 쓰는 경우가 많습니다. 이때 기본 거부(재귀 와일드카드)를 깔지 않으면, 한 앱의 실수가 다른 앱 데이터까지 노출시킵니다.

5위. 서비스 계정 키가 저장소에 올라가 있다

웹 설정의 apiKey는 공개돼도 정상이지만, 서버용 서비스 계정 키(JSON)가 공개 저장소나 앱 번들에 들어가면 데이터베이스 전체 권한이 노출됩니다. 키는 코드 밖에서 관리하고, 노출됐다면 즉시 교체해야 합니다.

고칠 때 주의

규칙을 갑자기 좁히면 기존 기능이 권한 오류를 냅니다. Firebase 에뮬레이터나 규칙 플레이그라운드로 주요 화면의 읽기·쓰기를 먼저 시험한 뒤 배포하세요. 단계별 점검 항목은 Firebase 보안 규칙 체크리스트에 있고, 개발을 몰라도 확인할 수 있는 무료 보안 체크리스트도 있습니다.

자주 묻는 질문