// docs / baas security / umbrella scanner
Scanner miskonfigurasi BaaS: temukan jalur data publik sebelum user
Penyedia Backend-as-a-Service — Supabase, Firebase, Clerk, Auth0, Appwrite, Convex — semuanya gagal dalam keamanan dengan bentuk yang sama: platform mengirimkan default yang masuk akal, pengembang (atau AI coding tool) mengambil pintasan, dan jalur publik terbuka antara penyerang tidak terautentikasi dan data pelanggan. Scanner miskonfigurasi BaaS adalah satu-satunya tool yang menyondir jalur itu dari luar dengan cara yang akan dilakukan penyerang. Artikel ini memetakan lima kelas miskonfigurasi berulang, menjelaskan bagaimana scan BaaS payung FixVibe bekerja, membandingkan empat penyedia utama, dan membandingkan scanner sadar-BaaS dengan tool DAST umum.
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
Clerk webhooks, Stripe webhooks, Supabase webhooks all sign their payloads. A handler that doesn't verify the signature is a database-write primitive for any attacker who guesses the URL.
Bagaimana scan BaaS payung FixVibe bekerja
Fase BaaS FixVibe berjalan dalam tiga tahap, masing-masing menghasilkan temuan berbeda:
- Stage 1 — find the providers. FixVibe loads the deployed app and identifies which BaaS providers it talks to — Supabase, Firebase, Clerk, Auth0 and others — from the configuration the browser receives.
- Stage 2 — provider checks. For each provider found, FixVibe runs that provider's checks: open Supabase tables, open Firebase rules, Clerk and Auth0 key exposure, and service-tier credentials in the bundle. Each provider is checked independently — a Supabase finding doesn't block the Firebase scan.
- 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_roleatau keysb_secret_*yang bocor di bundle, skema yang terekspos via daftar OpenAPI anonim. Lihat Scanner RLS Supabase dan Checklist storage. - Firebase: aturan
if truepada 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:
| Aspek | FixVibe (DAST sadar-BaaS) | DAST umum (Burp / ZAP) | SAST / SCA (Snyk / Semgrep) |
|---|---|---|---|
| Cakupan BaaS | Check native untuk Supabase, Firebase, Clerk, Auth0, Appwrite | Crawl web generik; tanpa sondir spesifik penyedia | Analisis statis hanya repo; tanpa validasi produksi |
| Waktu setup | URL → run → results usually in under a minute | Berjam-jam: konfigurasi spider, auth, scope | Sehari: integrasikan ke CI repo |
| Apa yang dibuktikannya | Eksposur runtime produksi dengan bukti tingkat-HTTP | Vuln web-app (XSS, SQLi); BaaS via konfigurasi manual | Pola kode yang mungkin atau tidak ter-deploy |
| Inspeksi bundle JavaScript | Every shipped chunk, with provider-aware key detection | Terbatas — hanya grep berbasis string | Ya, tetapi hanya sisi repo, tidak ter-deploy |
| Scan kontinu | Bulanan / saat-deploy via API + MCP | Manual; konfigurasi jadwal sendiri | Per-commit (bagus untuk kode, buta terhadap runtime) |
| Harga untuk solo / tim kecil | Free plan; paid plans for active and repo scans | Burp Suite Professional is paid (Community Edition is free); ZAP is free and open source | Snyk and Semgrep both offer free tiers; paid tiers add scale |
Where a BaaS scan fits
A BaaS-aware scan checks what your live app exposes. Pair it with FixVibe's GitHub repo scans or another code scanner for source and dependency issues, and with a manual penetration test before a major launch or compliance audit.
Pertanyaan yang sering diajukan
Apakah scan payung bekerja jika aplikasi saya menggunakan dua penyedia BaaS (mis. Supabase + Clerk)?
Ya — fingerprinting penyedia dan sondir per-penyedia bersifat independen. Scanner mendeteksi keduanya, menjalankan kedua suite check, dan melaporkan korelasi lintas-penyedia (mis. template JWT Supabase dari Clerk yang mengirim email sebagai claim di samping RLS yang hilang).
Bagaimana ini berbeda dari menjalankan Burp Suite Pro terhadap aplikasi saya?
Burp adalah workbench DAST umum. Di luar kotak, Burp tidak tahu apa itu PostgREST, Firestore, atau path callback Auth0 — Anda harus mengonfigurasi scope secara manual, menulis ekstensi, dan menafsirkan response. FixVibe dikirim dengan sondir BaaS bawaan dan format bukti yang berbentuk-BaaS. Burp menang pada cakupan web-app umum (XSS, SQLi, logika bisnis); FixVibe menang pada temuan spesifik-BaaS.
Bagaimana dengan App Check (Firebase) atau attestation (Apple / Google)?
App Check membuat scan eksternal oportunistik mengembalikan 403 pada setiap sondir — hasil yang benar untuk bot jahat. Scan FixVibe dari klien yang tidak diatestasi berperilaku dengan cara yang sama. Jika Anda mengaktifkan App Check dan FixVibe masih melaporkan temuan, itu berarti aturan Anda terbuka untuk klien yang diatestasi juga, yang merupakan risiko sebenarnya. App Check + aturan yang benar adalah pola defense-in-depth.
Dapatkah scanner memverifikasi perbaikan saya?
Yes — re-run after applying the fix. Findings keep the same identity across runs, so a finding that was open in run 1 and absent in run 2 is proof the fix landed.
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.