파이어스토어 보안규칙 흔한 실수

왜 규칙이 유일한 방어선인가

전통적인 서버 앱은 모든 요청이 서버를 거치며 그곳에서 권한을 검사합니다. 반면 Firestore는 앱이 DB에 직접 붙습니다. 중간에 가로막는 서버가 없으니, ‘누가 무엇을 읽고 쓸 수 있는가’를 오직 보안규칙이 결정합니다. 규칙이 느슨하면, 앱 화면에서 막아둔 것과 무관하게 주소만 알면 DB를 직접 조회·수정할 수 있습니다. 규칙은 ‘있으면 좋은 것’이 아니라 방어선 그 자체입니다.

실수 1 — 테스트 모드 방치

프로젝트를 만들 때 ‘테스트 모드로 시작’을 고르면 보통 아래처럼 한동안 전체 허용 규칙이 깔립니다. 개발이 바빠지면 이걸 그대로 두고 출시하는 사고가 가장 흔합니다.

// 위험: 날짜까지 누구나 읽기·쓰기 가능 (출시하면 안 됨)
match /{document=**} {
  allow read, write: if request.time < timestamp.date(2026, 11, 1);
}

테스트 모드는 ‘개발 전용’입니다. 기간 안에는 전체 공개, 기간이 지나면 전체 차단으로 바뀌어 앱이 멈춥니다. 출시 전 반드시 실제 규칙으로 교체하세요.

실수 2 — allow if true로 전체 공개

같은 컬렉션, 위험한 규칙 vs 안전한 규칙

위험

allow read, write: if true; — 전부 공개
로그인 여부조차 보지 않음
주소만 알면 외부에서 수정·삭제 가능

안전

로그인 확인 request.auth != null
소유자만 request.auth.uid == resource.data.uid
읽기·쓰기를 나눠 최소 권한만 허용

if true는 ‘문을 떼어 놓은 것’과 같습니다. 최소한 로그인·소유자 확인을 넣어야 합니다.

// 권장: 로그인 + 소유자 본인만
match /orders/{orderId} {
  allow read: if request.auth != null
              && request.auth.uid == resource.data.uid;
  allow create: if request.auth != null
              && request.auth.uid == request.resource.data.uid;
}

실수 3 — 규칙을 ‘필터’로 착각

흔한 오해가 ‘규칙을 걸면 조건에 맞는 문서만 걸러서 준다’는 생각입니다. 규칙은 필터가 아니라 허용/거부 판정입니다. 쿼리가 규칙상 접근 불가한 문서를 하나라도 건드리면, 걸러주는 게 아니라 쿼리 전체가 거부됩니다. 그래서 앱의 쿼리와 규칙의 조건을 ‘짝이 맞게’ 설계해야 하며, ‘일단 넓게 열고 앱에서 거른다’는 접근은 데이터 유출로 이어집니다.

실수 4 — 로그인만 보고 소유자 확인을 빼먹음

allow read: if request.auth != null 까지만 두면, ‘로그인한 아무나’가 남의 데이터까지 읽을 수 있습니다. 로그인은 ‘누구인지’만 확인할 뿐, ‘이 문서의 주인인지’는 따로 봐야 합니다. 개인 데이터라면 resource.data.uid == request.auth.uid 처럼 소유자 조건을 반드시 더하세요.

실수 5 — 하위 컬렉션·기본 거부를 빠뜨림

규칙은 경로마다 적용됩니다. 상위 문서만 막고 하위 컬렉션(/users/{id}/private/...)에 규칙을 안 두면, 그쪽이 의도와 다르게 열려 있을 수 있습니다. 기본은 ‘명시적으로 허용한 것 외엔 모두 거부’가 되도록, 넓은 allow를 두지 말고 경로별로 필요한 권한만 더하는 방식으로 작성하세요.

점검·테스트 방법

규칙 점검 순서

테스트 모드·if true 수색규칙 전체에서 전체 허용 구문이 남아 있는지부터 제거.

시뮬레이터로 ‘거부’ 확인로그인 안 함·남의 문서 접근이 막히는지를 콘솔 시뮬레이터로 확인.

에뮬레이터 자동 테스트허용/거부 케이스를 테스트로 고정해, 규칙을 고칠 때마다 회귀 확인.

민감 로직은 서버로결제·적립 등 조작되면 안 되는 작업은 규칙에 기대지 말고 서버/Functions로.

‘되는지’가 아니라 ‘안 돼야 할 게 막히는지’를 확인하는 게 보안 테스트의 핵심입니다.

자주 묻는 질문

테스트 모드는 얼마나 위험한가요?

매우 위험합니다. 테스트 모드는 보통 ‘일정 기간 누구나 읽기·쓰기 허용’이라, 그 사이 주소만 알면 외부에서 DB를 통째로 읽거나 지울 수 있습니다. 기간이 지나면 반대로 전체 차단으로 바뀌어 앱이 멈추기도 합니다. 테스트 모드는 개발 초반에만, 반드시 제대로 된 규칙으로 교체하세요.

규칙만 잘 쓰면 서버 없이도 안전한가요?

상당 부분 가능하지만, 민감한 검증(결제·포인트 적립 등 조작되면 안 되는 로직)은 규칙만으로 한계가 있습니다. 그런 작업은 서버(또는 Cloud Functions)를 거치게 하고, 규칙은 접근 범위를 좁히는 역할로 쓰는 게 안전합니다.

규칙이 잘 됐는지 어떻게 확인하죠?

Firebase 콘솔의 규칙 시뮬레이터로 ‘로그인 안 한 사용자’, ‘다른 사람 문서’ 같은 상황을 넣어 거부되는지 확인하고, 에뮬레이터로 자동화 테스트를 돌리는 방법이 있습니다. ‘되게’가 아니라 ‘안 돼야 할 게 막히는지’를 확인하는 게 핵심입니다.

이미 열려 있었다면 데이터가 샜을까요?

열려 있던 기간·주소 노출 정도에 따라 다르지만, 샜을 가능성을 전제로 대응하는 게 안전합니다. 규칙을 먼저 닫고, 노출됐을 수 있는 키·개인정보를 점검하세요. 자세한 대응은 보안 점검 가이드를 참고하세요.

무료 점검부터 시작하세요

지금 Firestore 규칙을 그대로 붙여 보내주시면, 위험한 부분과 고칠 지점을 짚어드립니다. 오래된 앱이면 전체 보안 점검도 함께 가능합니다.

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

문의: appmonster.kr@gmail.com