Firebase 보안 규칙은 Firestore, 실시간 데이터베이스, Cloud Storage [S1]의 데이터를 보호하기 위한 세분화된 서버 시행 메커니즘을 제공합니다. Firebase 애플리케이션은 클라이언트 측에서 직접 이러한 클라우드 서비스와 상호 작용하는 경우가 많기 때문에 이러한 규칙은 백엔드 데이터 [S1]에 대한 무단 액세스를 방지하는 유일한 장벽을 나타냅니다.
허용 규칙의 영향
잘못 구성된 규칙으로 인해 심각한 데이터 노출이 발생할 수 있습니다. [S2]. 규칙이 과도하게 허용되도록 설정된 경우(예: 전역 액세스를 허용하는 기본 '테스트 모드' 설정 사용) 프로젝트 ID를 아는 모든 사용자는 전체 데이터베이스 콘텐츠 [S2]를 읽거나 수정하거나 삭제할 수 있습니다. 이는 모든 클라이언트 측 보안 조치를 우회하며 민감한 사용자 정보가 손실되거나 전체 서비스가 중단될 수 있습니다. [S2].
근본 원인: 권한 부여 논리 부족
이러한 취약점의 근본 원인은 일반적으로 사용자 ID 또는 리소스 속성 [S3]를 기반으로 액세스를 제한하는 특정 조건을 구현하지 못하기 때문에 발생합니다. 개발자는 request.auth 개체 [S3]의 유효성을 검사하지 않는 프로덕션 환경에서 기본 구성을 활성 상태로 두는 경우가 많습니다. request.auth를 평가하지 않으면 시스템은 합법적으로 인증된 사용자와 익명 요청자 [S3]를 구별할 수 없습니다.
기술적 문제 해결
Firebase 환경을 보호하려면 개방형 액세스에서 최소 권한 원칙 모델로 전환해야 합니다.
- 인증 시행:
request.auth개체가 null [S3]가 아닌지 확인하여 모든 중요한 경로에 유효한 사용자 세션이 필요한지 확인하세요. - ID 기반 액세스 구현: 사용자의 UID(
request.auth.uid)를 문서 내 필드 또는 문서 ID 자체와 비교하여 사용자가 자신의 데이터 [S3]에만 액세스할 수 있도록 하는 규칙을 구성합니다. - 세분화된 권한 범위: 컬렉션에 전역 와일드카드를 사용하지 마세요. 대신 각 컬렉션 및 하위 컬렉션에 대한 특정 규칙을 정의하여 잠재적인 공격 표면 [S2]를 최소화하세요.
- 에뮬레이터 제품군을 통한 유효성 검사: Firebase 에뮬레이터 제품군을 사용하여 로컬에서 보안 규칙을 테스트합니다. 이를 통해 라이브 환경 [S2]에 배포하기 전에 다양한 사용자 페르소나에 대한 액세스 제어 논리를 확인할 수 있습니다.
FixVibe가 이를 테스트하는 방법
이제 FixVibe에는 이 스캔이 읽기 전용 BaaS 스캔으로 포함됩니다. baas.firebase-rules는 최신 initializeApp(...) 번들 형태를 포함하여 동일한 원본 JavaScript 번들에서 Firebase 구성을 추출한 다음 인증되지 않은 읽기 전용 요청으로 실시간 데이터베이스, Firestore 및 Firebase 스토리지를 확인합니다. Firestore의 경우 먼저 루트 컬렉션 나열을 시도합니다. 목록이 차단되면 users, accounts, customers, orders, payments, messages와 같은 일반적인 민감한 컬렉션 이름도 검색합니다. admin 및 settings. 성공적인 익명 읽기 또는 나열만 보고하며 고객 문서 내용을 작성, 삭제 또는 저장하지 않습니다.