왜 이렇게 자주 새나
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 프로젝트를 여러 서비스가 컬렉션 접두사로 나눠 쓰는 경우가 많습니다. 이때 기본 거부(재귀 와일드카드)를 깔지 않으면, 한 앱의 실수가 다른 앱 데이터까지 노출시킵니다(관련: Firebase 프로젝트 공유).
5위. 서비스 계정 키가 저장소에 올라가 있다
웹 설정의 apiKey는 공개돼도 정상이지만, 서버용 서비스 계정 키(JSON)가 공개 저장소나 앱 번들에 들어가면 데이터베이스 전체 권한이 노출됩니다. 키는 코드 밖에서 관리하고, 노출됐다면 즉시 교체해야 합니다(관련: API키 노출 조치).
실수 vs 올바른 방향
흔한 실수
- 테스트 규칙(전부 허용)을 운영에 방치
- auth != null 만으로 끝냄
- 관리자 판별을 화면에만 의존
- 공유 프로젝트에 기본 거부 없음
올바른 방향
- 기본 거부 후 필요한 경로만 허용
- uid == userId 로 본인만
- Custom Claims로 서버에서 판별
- 앱별 접두사 + 재귀 와일드카드 거부
고칠 때 주의
규칙을 갑자기 좁히면 기존 기능이 권한 오류를 냅니다. Firebase 에뮬레이터나 규칙 플레이그라운드로 주요 화면의 읽기·쓰기를 먼저 시험한 뒤 배포하세요. 단계별 점검 항목은 Firebase 보안 규칙 체크리스트에 있고, 개발을 몰라도 확인할 수 있는 무료 보안 체크리스트도 있습니다.
자주 묻는 질문
규칙을 바꾸면 앱이 멈추지 않나요?
허용 범위를 좁히면 기존 기능이 권한 오류를 낼 수 있어, 에뮬레이터로 먼저 시험한 뒤 배포합니다. 점검·조치 시 이 과정을 함께 진행합니다.
auth != null 만 쓰면 왜 위험한가요?
익명 로그인이 켜져 있으면 누구나 로그인 상태가 될 수 있어, 로그인만 확인하는 규칙은 사실상 전부 허용과 비슷해집니다. request.auth.uid == userId처럼 본인 문서만 허용하도록 좁혀야 합니다.
점검을 맡기면 무엇을 받나요?
인증·권한, DB·Storage 규칙, 키 노출, 개인정보 암호화, 백업, SSL을 확인해 위험도별 리포트와 긴급 조치를 드립니다.
ISMS 같은 인증 컨설팅인가요?
아닙니다. 운영 중인 앱·웹의 실무 점검과 조치 서비스입니다.
무료 점검부터 시작하세요
같은 문제를 겪고 있다면 프로젝트 구성만 알려주셔도 규칙·권한·키 노출 위험을 먼저 진단해 드립니다.
문의: appmonster.kr@gmail.com
함께 보기: Firebase 보안 규칙 체크리스트 · Firebase 프로젝트 공유 · API키 노출