Scanner miskonfigurasi BaaS: temukan jalur data publik sebelum user

Mengapa miskonfigurasi BaaS memiliki bentuk berulang

Setiap platform BaaS mengikuti arsitektur yang sama: backend terkelola dengan SDK klien tipis yang berbicara dengannya dari browser. Klien yang menghadap browser memerlukan beberapa kredensial — anon key, publishable key, project ID Firebase — untuk mengidentifikasi dirinya ke backend. Kredensial itu sengaja publik; keamanan arsitektur bertumpu pada kontrol akses tingkat platform (RLS, aturan, allowlist) melakukan tugasnya.

AI coding tools membangun di atas arsitektur ini tanpa menginternalisasi lapisan kontrol platform. Mereka menyambungkan SDK klien dengan benar, menerima aturan default platform yang permisif (yang ada untuk keramahan tutorial), dan mengirim. Bentuk berulangnya adalah: kredensial publik + aturan default permisif + override yang hilang = paparan data. Lima kelas miskonfigurasi di bawah ini semuanya adalah varian dari bentuk ini.

Lima kelas miskonfigurasi berulang

Ini muncul di setiap penyedia BaaS. Scan lengkap mencakup kelima terhadap setiap penyedia yang digunakan:

Kelas 1: Key salah di bundle browser

Browser mengirim key rahasia/admin (service_role Supabase, private key Firebase Admin SDK, sk_* Clerk, client secret Auth0) alih-alih padanan publik/anon. Browser menjadi klien admin tanpa batasan. Dicakup oleh check bundle-secrets FixVibe.

Kelas 2: Lapisan kontrol akses dinonaktifkan atau permisif

RLS mati, aturan Firebase adalah if true, daftar callback Auth0 di-wildcard. Kredensial di browser adalah yang benar — tetapi batas tingkat platform yang dimaksudkan untuk membatasinya tidak melakukan tugasnya.

Kelas 3: Baca anonim atas sumber daya sensitif

Koleksi Firestore yang dapat dibaca anon, bucket storage Supabase yang dapat di-list anon, Auth0 management API yang dapat diakses anon. Scan bertanya: "tanpa kredensial, apa yang dapat saya baca?"

Kelas 4: Artefak mode test di produksi

Key test (pk_test_*, sb_test_*) di deploy produksi; aplikasi Firebase mode dev dapat dijangkau dari domain live; aplikasi Auth0 tenant test dengan pengaturan lebih lemah daripada produksi. Scan membandingkan key runtime terhadap prefix produksi yang diharapkan.

Kelas 5: Verifikasi tanda tangan webhook tidak ada

Webhook Clerk, webhook Stripe, webhook Supabase semuanya menandatangani payload mereka. Handler yang tidak memverifikasi tanda tangan adalah primitif tulis-database untuk penyerang mana pun yang menebak URL. Terdeteksi via bentuk response — request tidak ditandatangani yang mendapat 200 berarti verifikasi dilewatkan.

Bagaimana scan BaaS payung FixVibe bekerja

Fase BaaS FixVibe berjalan dalam tiga tahap, masing-masing menghasilkan temuan berbeda:

1. <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. Tahap 2 — sondir spesifik penyedia. Untuk setiap penyedia yang terdeteksi, scanner menjalankan check spesifik penyedia: baas.supabase-rls menyondir PostgREST; baas.firebase-rules menyondir Firestore + RTDB + Storage; baas.clerk-auth0 memvalidasi prefix key yang ter-bundle; check bundle-secrets memvalidasi bahwa tidak ada kredensial tingkat-service yang bocor. Setiap sondir berjalan secara independen — temuan Supabase tidak memblokir scan Firebase.
3. Tahap 3 — korelasi lintas-penyedia. Scanner merujuk silang temuan. Service-role key Supabase yang bocor di samping RLS yang hilang lebih parah daripada temuan salah satunya saja — laporan memunculkan ini. Beberapa identity provider (Clerk + Auth0 + auth kustom) dalam aplikasi yang sama adalah temuan struktural yang ditandai untuk ditinjau.

Setiap sondir bersifat pasif: paling banyak satu baca anonim per sumber daya, dengan bentuk response dicatat tetapi isi baris tidak pernah dipaginasi atau disimpan. Sondir tulis dan modifikasi diperketat di balik verifikasi kepemilikan domain — mereka tidak pernah berjalan terhadap target yang belum diverifikasi.

Apa yang ditemukan scanner per penyedia

Setiap penyedia BaaS memiliki permukaan berbeda dan strategi scan yang berbeda. Inilah yang tercakup:

• Supabase: RLS yang hilang pada tabel, bucket storage yang dapat di-list anon, JWT service_role atau key sb_secret_* yang bocor di bundle, skema yang terekspos via daftar OpenAPI anonim. Lihat Scanner RLS Supabase dan Checklist storage.
• Firebase: aturan if true pada Firestore, Realtime Database, dan Cloud Storage; bucket Storage yang dapat di-list anon; penegakan App Check yang hilang. Lihat Scanner aturan Firebase dan Penjelasan aturan if-true.
• Clerk: secret key sk_* yang ter-bundle, pk_test_* di produksi, verifikasi tanda tangan webhook yang hilang, origin yang diizinkan wildcard. Lihat Checklist Clerk.
• Auth0: client secret yang ter-bundle, grant Implicit diaktifkan, URL callback / logout wildcard, PKCE yang hilang pada SPA. Lihat Checklist Auth0.

Bagaimana scanner BaaS dibandingkan dengan tool DAST dan SAST umum

Scanner sadar-BaaS melakukan pekerjaan spesifik yang tidak dilakukan tool lain. Perbandingannya:

Lingkup yang jujur: apa yang tidak digantikan scanner ini

Scanner DAST sadar-BaaS adalah tool yang terfokus, bukan program keamanan lengkap. Ia tidak:

• Menggantikan SAST atau SCA. Analisis statis menemukan CVE dependensi (Snyk, Semgrep) dan kerentanan tingkat-kode (SonarQube) yang tidak dapat dilakukan scanner DAST. Jalankan keduanya.
• Menggantikan pengujian penetrasi manual. Pentester manusia menemukan cacat logika bisnis, kasus tepi otorisasi, dan kerentanan yang dirantai yang tidak dapat dilakukan scanner mana pun. Pekerjakan pentester sebelum peluncuran besar atau audit kepatuhan.
• Mengaudit kode atau repo Anda untuk secret di history git. Check bundle-secrets mencakup apa yang saat ini ter-deploy, bukan apa yang secara historis di-commit. Gunakan git-secrets atau gitleaks untuk kebersihan repo.
• Mencakup layanan backend non-BaaS. Jika aplikasi Anda menggunakan backend kustom (Express, Rails, Django, FastAPI), FixVibe men-scan permukaan HTTP-nya tetapi tidak menyondir database atau infrastruktur di belakangnya. Itu adalah wilayah DAST + SAST umum.

Pertanyaan yang sering diajukan

Langkah berikutnya

Jalankan scan FixVibe gratis terhadap URL produksi Anda — check fase-BaaS dikirim pada setiap paket, termasuk tier gratis. Untuk pendalaman spesifik penyedia, artikel individual di bagian ini mencakup setiap penyedia secara detail: Supabase RLS, Eksposur service-key Supabase, Supabase storage, Aturan Firebase, Firebase if-true, Clerk, dan Auth0.