// docs / baas security / umbrella scanner
BaaS 설정 오류 스캐너: 사용자보다 먼저 공개 데이터 경로 찾기
Backend-as-a-Service 제공자 — Supabase, Firebase, Clerk, Auth0, Appwrite, Convex — 는 모두 같은 모양으로 보안에 실패합니다: 플랫폼이 합리적인 기본값을 제공하고, 개발자(또는 AI 코딩 도구)가 지름길을 택하며, 인증되지 않은 공격자와 고객 데이터 사이에 공개 경로가 열립니다. BaaS 설정 오류 스캐너는 공격자처럼 외부에서 그 경로를 탐사하는 유일한 도구입니다. 이 기사는 다섯 가지 반복되는 설정 오류 클래스를 매핑하고, FixVibe 우산 BaaS 스캔이 어떻게 작동하는지 설명하며, 네 주요 제공자를 비교하고, BaaS 인식 스캐너를 일반 DAST 도구와 대비합니다.
BaaS 설정 오류가 왜 반복되는 모양을 가지는가
모든 BaaS 플랫폼은 같은 아키텍처를 따릅니다: 브라우저에서 통신하는 얇은 클라이언트 SDK가 있는 관리형 백엔드. 브라우저 대면 클라이언트는 백엔드에 자신을 식별하기 위해 일부 자격 증명 — anon 키, 게시 가능 키, Firebase 프로젝트 ID — 이 필요합니다. 그 자격 증명은 의도적으로 공개됩니다. 아키텍처의 안전성은 플랫폼 수준 접근 통제(RLS, 규칙, 허용 목록)가 제 역할을 하는 데 달려 있습니다.
AI 코딩 도구는 이 아키텍처 위에 구축하지만 플랫폼 통제 계층을 내재화하지 않습니다. 클라이언트 SDK를 올바르게 연결하고, 플랫폼의 기본 허용 규칙(튜토리얼 친화성을 위해 존재)을 수락하고, 출시합니다. 반복되는 모양은: 공개 자격 증명 + 허용 기본 규칙 + 누락된 재정의 = 데이터 노출. 아래의 다섯 가지 설정 오류 클래스는 모두 이 모양의 변형입니다.
다섯 가지 반복되는 설정 오류 클래스
이들은 모든 BaaS 제공자에 걸쳐 나타납니다. 완전한 스캔은 사용 중인 모든 제공자에 대해 다섯 가지 모두를 포함합니다:
클래스 1: 브라우저 번들의 잘못된 키
브라우저가 공개/anon 동등물 대신 비밀/관리자 키(Supabase service_role, Firebase Admin SDK 비공개 키, Clerk sk_*, Auth0 클라이언트 비밀)를 출시합니다. 브라우저는 제약 없는 관리자 클라이언트가 됩니다. FixVibe의 번들 비밀 검사가 다룹니다.
클래스 2: 접근 통제 계층이 비활성화되었거나 허용적
RLS가 꺼져 있고, Firebase 규칙이 if true이고, Auth0 콜백 목록이 와일드카드입니다. 브라우저의 자격 증명은 올바른 것이지만 — 이를 제약해야 할 플랫폼 수준 경계가 제 역할을 하지 않습니다.
클래스 3: 민감한 리소스의 익명 읽기
익명 읽기 가능한 Firestore 컬렉션, 익명 나열 가능한 Supabase 스토리지 버킷, 익명 접근 가능한 Auth0 관리 API. 스캔은 묻습니다: "자격 증명이 없으면 무엇을 읽을 수 있는가?"
클래스 4: 프로덕션의 테스트 모드 잔재
프로덕션 배포의 테스트 키(pk_test_*, sb_test_*); 라이브 도메인에서 도달 가능한 개발 모드 Firebase 앱; 프로덕션보다 약한 설정의 테스트 테넌트 Auth0 애플리케이션. 스캔은 런타임 키를 예상 프로덕션 접두사와 비교합니다.
클래스 5: 웹훅 서명 검증 누락
Clerk 웹훅, Stripe 웹훅, Supabase 웹훅 모두 페이로드에 서명합니다. 서명을 확인하지 않는 핸들러는 URL을 추측하는 모든 공격자에게 데이터베이스 쓰기 프리미티브입니다. 응답 모양으로 탐지됩니다 — 200을 받는 서명되지 않은 요청은 검증이 건너뛰어졌다는 의미입니다.
FixVibe 우산 BaaS 스캔 작동 방식
FixVibe의 BaaS 단계는 세 단계로 실행되며 각각 별개의 발견을 생성합니다:
- <strong>Stage 1 — provider fingerprinting.</strong> The scanner crawls the deployed app, parses every JavaScript chunk, and identifies which BaaS providers the app uses. Each provider has a distinctive runtime signature: Supabase uses <code>*.supabase.co</code>; Firebase uses <code>firebase.initializeApp({ projectId: ... })</code>; Clerk uses <code>pk_*</code> keys with a known prefix; Auth0 uses <code>clientId</code> and <code>domain</code>. The scanner records which providers are present and extracts the project identifiers.
- 2단계 — 제공자 특정 탐사. 탐지된 각 제공자에 대해 스캐너는 제공자 특정 검사를 실행합니다:
baas.supabase-rls는 PostgREST를 탐사하고,baas.firebase-rules는 Firestore + RTDB + Storage를 탐사하며,baas.clerk-auth0는 번들된 키의 접두사를 확인하고, 번들 비밀 검사는 서비스 등급 자격 증명이 유출되지 않았는지 확인합니다. 각 탐사는 독립적으로 실행됩니다 — Supabase 발견이 Firebase 스캔을 차단하지 않습니다. - 3단계 — 제공자 간 상관관계. 스캐너는 발견을 상호 참조합니다. 누락된 RLS와 함께 유출된 Supabase 서비스 역할 키는 단독 발견보다 더 심각합니다 — 보고서는 이를 표면화합니다. 같은 앱의 여러 신원 제공자(Clerk + Auth0 + 사용자 정의 인증)는 검토를 위해 플래그된 구조적 발견입니다.
모든 탐사는 수동입니다: 리소스당 최대 한 번의 익명 읽기, 응답 모양은 기록되지만 행 내용은 페이지를 매기거나 저장되지 않습니다. 쓰기 및 수정 탐사는 확인된 도메인 소유권 뒤에서 게이트되며 — 확인되지 않은 대상에 대해 결코 실행되지 않습니다.
스캐너가 제공자별로 찾는 것
각 BaaS 제공자는 다른 표면과 다른 스캔 전략을 가집니다. 다루는 내용:
- Supabase: 테이블의 누락된 RLS, 익명 나열 가능한 스토리지 버킷, 번들의 유출된
service_roleJWT 또는sb_secret_*키, 익명 OpenAPI 나열을 통해 노출된 스키마. Supabase RLS 스캐너와 스토리지 체크리스트를 참조하세요. - Firebase: Firestore, Realtime Database, Cloud Storage의
if true규칙; 익명 나열 가능한 Storage 버킷; 누락된 App Check 적용. Firebase 규칙 스캐너와 If-true 규칙 설명자를 참조하세요. - Clerk: 번들된
sk_*비밀 키, 프로덕션의pk_test_*, 누락된 웹훅 서명 확인, 와일드카드 허용 오리진. Clerk 체크리스트를 참조하세요. - Auth0: 번들된 클라이언트 비밀, 활성화된 Implicit 권한 부여, 와일드카드 콜백/로그아웃 URL, SPA의 누락된 PKCE. Auth0 체크리스트를 참조하세요.
BaaS 스캐너가 일반 DAST 및 SAST 도구와 비교되는 방법
BaaS 인식 스캐너는 다른 도구가 하지 않는 특정 작업을 합니다. 비교:
| 측면 | FixVibe (BaaS 인식 DAST) | 일반 DAST (Burp / ZAP) | SAST / SCA (Snyk / Semgrep) |
|---|---|---|---|
| BaaS 커버리지 | Supabase, Firebase, Clerk, Auth0, Appwrite에 대한 네이티브 검사 | 일반 웹 크롤; 제공자 특정 탐사 없음 | 리포지토리의 정적 분석만; 프로덕션 검증 없음 |
| 설정 시간 | URL → 실행 → 60초 내 결과 | 수 시간: 스파이더, 인증, 범위 구성 | 하루: 리포지토리 CI에 통합 |
| 증명하는 것 | HTTP 수준 증거가 있는 프로덕션 런타임 노출 | 웹 앱 취약점(XSS, SQLi); 수동 구성을 통한 BaaS | 배포될 수도 있고 안 될 수도 있는 코드 패턴 |
| JavaScript 번들 검사 | JWT 디코드, 비밀 접두사 매칭, 청크 순회 | 제한적 — 문자열 기반 grep만 | 있음, 그러나 리포지토리 측만, 배포된 것은 아님 |
| 지속적 스캔 | API + MCP를 통해 월별 / 배포 시 | 수동; 스케줄을 직접 구성 | 커밋당(코드에는 좋지만 런타임에는 맹목) |
| 솔로 / 소규모 팀 가격 | 무료 티어; 유료 $19/월부터 | Burp Pro $499/년; ZAP 무료지만 거짓 양성 많음 | Snyk 무료 / Semgrep 무료; 유료 티어 $25/개발자부터 |
정직한 범위: 이 스캐너가 대체하지 않는 것
BaaS 인식 DAST 스캐너는 집중된 도구이며 완전한 보안 프로그램이 아닙니다. 다음을 하지 않습니다:
- SAST 또는 SCA 대체. 정적 분석은 DAST 스캐너가 할 수 없는 종속성 CVE(Snyk, Semgrep)와 코드 수준 취약점(SonarQube)을 찾습니다. 둘 다 실행하세요.
- 수동 침투 테스트 대체. 인간 침투 테스터는 어떤 스캐너도 할 수 없는 비즈니스 로직 결함, 권한 부여 엣지 케이스, 연결된 취약점을 찾습니다. 주요 출시나 컴플라이언스 감사 전에 침투 테스터를 고용하세요.
- git 히스토리의 비밀에 대해 코드나 리포지토리 감사. 번들 비밀 검사는 현재 배포된 것을 다루고, 과거에 커밋된 것은 다루지 않습니다. 리포지토리 위생을 위해
git-secrets또는gitleaks를 사용하세요. - 비-BaaS 백엔드 서비스 커버. 앱이 사용자 정의 백엔드(Express, Rails, Django, FastAPI)를 사용하면 FixVibe는 그 HTTP 표면을 스캔하지만, 그 뒤의 데이터베이스나 인프라를 탐사하지 않습니다. 그것은 일반 DAST + SAST 영역입니다.
자주 묻는 질문
내 앱이 두 BaaS 제공자(예: Supabase + Clerk)를 사용하면 우산 스캔이 작동하나요?
예 — 제공자 지문 채취와 제공자별 탐사는 독립적입니다. 스캐너는 둘 다 탐지하고, 두 검사 스위트를 실행하며, 제공자 간 상관관계를 보고합니다(예: 누락된 RLS와 함께 email을 클레임으로 발송하는 Clerk의 Supabase JWT 템플릿).
이것이 내 앱에 대해 Burp Suite Pro를 실행하는 것과 어떻게 다른가요?
Burp는 일반 DAST 워크벤치입니다. 바로 사용할 때 Burp는 PostgREST, Firestore, 또는 Auth0 콜백 경로가 무엇인지 모릅니다 — 범위를 수동으로 구성하고, 확장을 작성하며, 응답을 해석해야 합니다. FixVibe는 내장된 BaaS 탐사와 BaaS 모양 증거 형식이 함께 제공됩니다. Burp는 일반 웹 앱 커버리지(XSS, SQLi, 비즈니스 로직)에서 이깁니다. FixVibe는 BaaS 특정 발견에서 이깁니다.
App Check(Firebase) 또는 증명(Apple / Google)은 어떤가요?
App Check는 기회주의적 외부 스캔이 모든 탐사에서 403을 반환하게 합니다 — 악의적인 봇에 대한 올바른 결과입니다. 증명되지 않은 클라이언트에서의 FixVibe 스캔은 같은 방식으로 동작합니다. App Check가 활성화되었는데 FixVibe가 여전히 발견을 보고하면, 이는 규칙이 증명된 클라이언트에도 열려 있다는 의미이며, 이것이 진정한 위험입니다. App Check + 올바른 규칙이 심층 방어 패턴입니다.
스캐너가 내 수정을 확인할 수 있나요?
예 — 수정을 적용한 후 다시 실행하세요. 검사 ID(예: baas.supabase-rls)는 실행 간에 안정적이므로 발견을 비교할 수 있습니다: 실행 1에서 open이었고 실행 2에서 없는 발견은 수정이 적용되었다는 증거입니다.
다음 단계
프로덕션 URL에 대해 무료 FixVibe 스캔을 실행하세요 — BaaS 단계 검사는 무료 티어를 포함한 모든 플랜에서 제공됩니다. 제공자 특정 심층 분석은 이 섹션의 개별 기사가 각 제공자를 자세히 다룹니다: Supabase RLS, Supabase 서비스 키 노출, Supabase 스토리지, Firebase 규칙, Firebase if-true, Clerk, Auth0.