Firebase: 신원, 권한, 저장소, 메시지 구분하기

핵심 요약

Firebase에는 SDK, 접근 통제, 요금 조건이 다른 서비스가 있습니다. 사용자 식별은 모든 데이터에 대한 허가가 아닙니다. 서비스마다 보안과 비용을 평가해야 합니다.

보안 키 두 개, 빈 카드와 버건디 서류철이 있는 가상의 무인 신원 확인실
이 글의 목차

Firebase에는 SDK, 접근 통제, 요금 조건이 다른 서비스가 있습니다. 사용자 식별은 모든 데이터에 대한 허가가 아닙니다. 서비스마다 보안과 비용을 평가해야 합니다.

인증과 권한 부여

Firebase Authentication은 로그인을 관리하며 권한은 별도로 정해야 합니다. Cloud Firestore의 웹·모바일 클라이언트는 Security Rules를 사용합니다. 서버 라이브러리는 이를 우회하고 IAM을 사용하므로 한 통제가 두 경로를 모두 덮는다고 가정하면 안 됩니다. 문서의 웹 MFA는 Firebase Authentication with Identity Platform을 요구합니다.

데이터와 파일

Cloud Firestore와 Realtime Database는 별도 데이터베이스 서비스이고 Cloud Storage는 파일 같은 객체를 저장합니다. 단일 보안 규칙을 공유하지 않습니다. 현재 FAQ는 기존 버킷을 포함한 Cloud Storage for Firebase 사용에 Blaze를 요구하지만 무료 사용량이 남을 수 있습니다. 무료 구조라고 소개하기 전에 할당량과 청구를 확인합니다.

FCM 알림

FCM HTTP v1은 단기 OAuth 2.0 접근 토큰 등을 통한 서버 권한을 사용합니다. 관리 자격 증명을 클라이언트에 넣지 말고 신뢰할 수 있는 환경에서 전송합니다. 기기 등록 토큰은 수신 대상을 식별하며 사용자 ID 토큰이나 업무 권한이 아닙니다.

세션과 운영

ID 토큰, 갱신 토큰, 취소를 구분합니다. 암호학적 유효성이 지속적인 권한을 입증하지는 않습니다. 필요한 로그, 보관 기간, 비용 경고, 리소스별 통제를 정합니다. Firebase가 자동으로 GDPR 준수를 보장하지는 않습니다.

출처

편집 검토: 2026년 11월 1일.

리졸버에 신원 확인 결정을 반영하십시오.

로그인에 성공했다고 해서 그래프의 모든 필드에 권한이 부여되는 것은 아닙니다. 각 리졸버에 도달하는 신원 컨텍스트는 요청된 객체 및 민감한 데이터에 대한 검사를 지원해야 합니다.

  • 동일한 필드를 여러 역할과 소유자로 테스트하십시오.
  • 중첩 필드를 계산하기 전에 객체 접근을 거부합니다.
  • 역할 변경 또는 세션 종료 후 재실행합니다.

1차 자료: OWASP — GraphQL Cheat Sheet. 관련 방법: 실무 가이드 읽기.

API 페이지 분할과 일관된 내보내기

변하는 데이터는 내보내기 누락과 중복을 만들 수 있습니다.

  • 필터, 정렬과 같은 값의 순서를 결정할 키를 기록합니다. API가 스냅샷을 제공하는지 변하는 집합을 읽는지 확인합니다. 읽는 동안 생성과 삭제를 시험합니다. 커서가 있다고 데이터가 고정된 것은 아닙니다.
  • AIP-158에서는 빈 next_page_token이 종료 조건이며 짧거나 빈 결과 페이지가 종료 조건은 아닙니다. 가상 페이지 [A,B]와 [B,C]에는 네 행이 있지만 고유 식별자는 세 개입니다. 진행 없는 같은 커서도 감지하고 실제 API 계약을 따릅니다.
  • 배치를 영구 저장한 뒤 계속 상태를 확정합니다. 안정된 식별자로 중단 배치를 재처리하고 요청마다 권한을 확인합니다. 커서는 접근 허가가 아닙니다. 스냅샷이 만료되면 다시 시작하거나 명시한 정책으로 대조하고 다른 상태를 조용히 합치지 않습니다.

재현 가능한 수락 사례

가상 예시입니다. 고객이나 실제 관측 결과를 나타내지 않습니다.

사례 입력 보기
{
    "page_1_ids": [
        "A",
        "B"
    ],
    "page_2_ids": [
        "B",
        "C"
    ],
    "next_cursor": "c2",
    "empty_page_has_next_cursor": true
}

예상 판단

B가 반복됩니다. 식별자를 확인하고 빈 페이지 뒤에도 다음 커서가 있으면 계속합니다.

검증 절차

  1. 필터, 안정 순서 및 객체 식별을 정합니다.
  2. 중복과 다음 커서가 있는 빈 페이지를 시험합니다.
  3. 식별자와 실제 종료 조건을 보존합니다. 수신 객체와 고유 식별자를 대조하고 반복 커서를 표시하세요. 후속 페이지가 있는 빈 페이지를 수집 완료로 처리하지 마세요.

Google AIP-158 — Pagination

예상 행 수에 맞으면 내보내기가 완전한가요?

아닙니다. 빠진 식별자와 중복 식별자가 건수에서 상쇄될 수 있습니다. 식별자, 범위와 마감 시각을 비교하고 해결 못 한 차이를 기록하세요.

1차 자료: Google AIP-158 — Pagination. 관련 방법: 실무 가이드 읽기.

패스키: 도메인과 RP ID 변경 준비

계정, 웹 출처와 RP ID를 구분해 인증 정보를 조용히 다시 연결하지 않는 전환을 준비합니다.

  • 이전과 새 출처, RP ID와 연결 계정을 기록합니다. 같은 계정 이름이라고 패스키가 다른 RP ID에 유효해지지는 않습니다. WebAuthn의 허용 조합과 전환 중 가능한 접근 경로를 확인합니다.
  • 허가된 시험 환경에서 적절한 라이브러리로 챌린지, 출처, RP ID와 계정 연결을 확인합니다. 예상 밖 출처와 재사용 챌린지를 시험합니다. RP ID가 바뀌면 인증된 새 등록을 준비합니다. 행 복사를 키 이전으로 취급하지 않습니다.
  • 이전 인증 정보만 가진 사용자, 복구와 열린 세션을 시험합니다. 검증된 복귀와 함께 경로 개설과 종료 순서를 정합니다. 새 도메인 등록 성공이 모든 이전 세션의 폐기를 입증하지는 않습니다.

재현 가능한 수락 사례

가상 예시입니다. 고객이나 실제 관측 결과를 나타내지 않습니다.

사례 입력 보기
{
    "old_origin": "https://login.old.example",
    "old_rp_id": "old.example",
    "new_origin": "https://login.new.example",
    "new_rp_id": "new.example",
    "same_service_account": true,
    "expected": "authenticated_new_registration"
}

예상 판단

가상 예: 계정은 같지만 old.example에서 다른 RP ID의 new.example로 옮깁니다. 이전 인증 정보를 조용히 다시 연결하면 안 되며 새 등록은 계획한 인증 경로를 따라야 합니다.

W3C — Web Authentication Level 2

1차 자료: W3C — Web Authentication Level 2. 관련 방법: 실무 가이드 읽기.

신원: 인증 요소, 세션 및 복구

Firebase: 짧은 토큰이 전체 세션을 끝내지는 않는다

문서는 ID 토큰 수명을 한 시간으로 정하며 갱신 토큰으로 새 토큰을 받을 수 있습니다. 갱신 토큰 취소와 ID 토큰 취소 감지는 서로 다른 통제입니다.

  • 취소를 해당 계정과 연결한다.
  • checkRevoked 등 SDK에 문서화된 취소 검사를 사용한다.
  • 각 보호된 백엔드에서 오래된 토큰과 권한을 검사한다.

신원 통제 자세히 보기 →

출처 확인일 · NIST · Authenticator Event Management NIST · Session Management Firebase · Manage User Sessions