// docs / baas security / umbrella scanner
BaaS misconfiguration scanner: users से पहले public data paths ढूँढ़ें
Backend-as-a-Service providers — Supabase, Firebase, Clerk, Auth0, Appwrite, Convex — सभी एक ही आकार में security में fail होते हैं: प्लेटफ़ॉर्म समझदार defaults ship करता है, developer (या AI कोडिंग टूल) एक shortcut के लिए पहुँचता है, और एक unauthenticated हमलावर और customer data के बीच एक public path खुलता है। एक BaaS misconfiguration scanner एकमात्र टूल है जो उस path को बाहर से उसी तरह probe करता है जैसे एक हमलावर करेगा। यह लेख पाँच आवर्ती misconfiguration classes को map करता है, समझाता है कि FixVibe umbrella BaaS scan कैसे काम करता है, चार प्रमुख providers की तुलना करता है, और सामान्य DAST tools के विरुद्ध BaaS-aware scanner का contrast करता है।
BaaS misconfigurations का एक आवर्ती आकार क्यों होता है
हर BaaS प्लेटफ़ॉर्म एक ही architecture का अनुसरण करता है: एक managed backend जिसके साथ एक पतला client SDK है जो browser से इससे बात करता है। Browser-facing client को backend से अपनी पहचान कराने के लिए कुछ credential की आवश्यकता है — एक anon key, एक publishable key, एक Firebase project ID। वह credential जानबूझकर public है; architecture की सुरक्षा प्लेटफ़ॉर्म-level access controls (RLS, rules, allowlists) के अपना काम करने पर निर्भर करती है।
AI कोडिंग टूल इस architecture के ऊपर बिना platform-controls layer को internalise किए build करते हैं। वे client SDK को सही ढंग से wire करते हैं, प्लेटफ़ॉर्म के default permissive rules (जो tutorial-friendliness के लिए मौजूद हैं) को स्वीकार करते हैं, और ship करते हैं। आवर्ती आकार है: public credential + permissive default rule + missing override = data exposure। नीचे की पाँच misconfiguration classes सभी इस आकार के variants हैं।
पाँच आवर्ती misconfiguration classes
ये हर BaaS provider में दिखाई देते हैं। एक पूर्ण scan हर provider के विरुद्ध सभी पाँच को cover करता है:
Class 1: Browser bundle में गलत key
Browser public/anon समकक्ष के बजाय secret/admin key (Supabase service_role, Firebase Admin SDK private key, Clerk sk_*, Auth0 client secret) ship करता है। Browser एक unconstrained admin client बन जाता है। FixVibe के bundle-secrets check द्वारा covered।
Class 2: Access-control layer disabled या permissive
RLS बंद है, Firebase rules if true हैं, Auth0 callback list wildcarded है। Browser में credential सही है — पर प्लेटफ़ॉर्म-level boundary जो इसे constrain करने वाली थी, अपना काम नहीं कर रही।
Class 3: संवेदनशील resources की Anonymous reads
Anon-readable Firestore collections, anon-listable Supabase storage buckets, anon-accessible Auth0 management API। Scan पूछता है: "कोई credentials नहीं, मैं क्या पढ़ सकता हूँ?"
Class 4: Production में Test-mode artefacts
Production deploy में test keys (pk_test_*, sb_test_*); live domain से reachable dev-mode Firebase apps; production की तुलना में कमजोर settings वाले test-tenant Auth0 applications। Scan अपेक्षित production prefixes के विरुद्ध runtime keys की तुलना करता है।
Class 5: Webhook signature verification गायब
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.
FixVibe umbrella BaaS scan कैसे काम करता है
FixVibe का BaaS phase तीन चरणों में चलता है, हर एक विशिष्ट findings उत्पन्न करता है:
- 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.
- चरण 3 — cross-provider correlation. Scanner findings को cross-reference करता है। गायब RLS के साथ एक leaked Supabase service-role key केवल एक finding से अधिक गंभीर है — report इसे surface करती है। एक ही app में कई identity providers (Clerk + Auth0 + custom auth) समीक्षा के लिए flagged एक structural finding है।
हर probe passive है: प्रति resource अधिकतम एक anonymous read, response shape record के साथ पर row contents कभी paginated या store नहीं किए जाते। Write और modify probes verified domain ownership के पीछे gated हैं — वे कभी भी unverified targets के विरुद्ध नहीं चलते।
Scanner प्रति provider क्या ढूँढ़ता है
हर BaaS provider की एक अलग सतह और एक अलग scan strategy है। यहाँ क्या covered है:
- Supabase: tables पर गायब RLS, anon-listable storage buckets, bundle में leaked
service_roleJWT याsb_secret_*key, anonymous OpenAPI listing के माध्यम से exposed schemas। Supabase RLS scanner और Storage checklist देखें। - Firebase: Firestore, Realtime Database, और Cloud Storage पर
if truerules; anon-listable Storage buckets; गायब App Check enforcement। Firebase rules scanner और If-true rule explainer देखें। - Clerk: bundled
sk_*secret keys, production मेंpk_test_*, गायब webhook signature verification, wildcard allowed origins। Clerk checklist देखें। - Auth0: bundled client secrets, Implicit grant enabled, wildcard callback / logout URLs, SPAs पर गायब PKCE। Auth0 checklist देखें।
एक BaaS scanner सामान्य DAST और SAST tools की तुलना में कैसा है
एक BaaS-aware scanner विशिष्ट काम करता है जो अन्य tools नहीं करते। तुलना:
| पहलू | FixVibe (BaaS-जागरूक DAST) | सामान्य DAST (Burp / ZAP) | SAST / SCA (स्निक / सेमग्रेप) |
|---|---|---|---|
| BaaS कवरेज | Supabase, Firebase, Clerk, Auth0, Appwrite के लिए native checks | सामान्य web crawl; कोई provider-specific probes नहीं | केवल repo का static analysis; कोई production validation नहीं |
| सेटअप समय | URL → run → results usually in under a minute | घंटे: spider, auth, scope कॉन्फ़िगर करें | दिन: repo CI में integrate करें |
| यह क्या साबित करता है | HTTP-level evidence के साथ production-runtime exposure | Web-app vulns (XSS, SQLi); BaaS manual config के माध्यम से | Code patterns जो deploy हो सकते हैं या नहीं |
| जावास्क्रिप्ट बंडल निरीक्षण | Every shipped chunk, with provider-aware key detection | सीमित — केवल string-based grep | हाँ, पर केवल repo-side, deployed नहीं |
| निरंतर scanning | API + MCP के माध्यम से मासिक / on-deploy | Manual; स्वयं schedule कॉन्फ़िगर करें | Per-commit (code के लिए अच्छा, runtime के लिए अंधा) |
| Solo / छोटी team के लिए मूल्य | 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.
अक्सर पूछे जाने वाले प्रश्न
क्या umbrella scan तब काम करता है जब मेरी app दो BaaS providers (जैसे, Supabase + Clerk) का उपयोग करती है?
हाँ — provider fingerprinting और per-provider probes स्वतंत्र हैं। Scanner दोनों को detect करता है, दोनों check suites चलाता है, और cross-provider correlations report करता है (जैसे, Clerk से एक Supabase JWT template जो गायब RLS के साथ email को एक claim के रूप में ship करता है)।
यह अपनी app के विरुद्ध Burp Suite Pro चलाने से कैसे अलग है?
Burp एक सामान्य DAST workbench है। Out of the box, Burp नहीं जानता कि PostgREST, Firestore, या Auth0 callback path क्या है — आपको manually scope कॉन्फ़िगर करना है, extensions लिखना है, और responses को interpret करना है। FixVibe built-in BaaS probes और BaaS-shaped evidence formatting के साथ ship होता है। Burp सामान्य web-app coverage (XSS, SQLi, business logic) पर जीतता है; FixVibe BaaS-specific findings पर जीतता है।
App Check (Firebase) या attestation (Apple / Google) के बारे में क्या?
App Check opportunistic बाहरी scans को हर probe पर 403 return करने पर मजबूर करता है — एक दुर्भावनापूर्ण bot के लिए सही outcome। एक unattested client से FixVibe scan उसी तरह व्यवहार करता है। यदि आपके पास App Check enabled है और FixVibe फिर भी findings report करता है, तो इसका मतलब है कि आपके rules attested clients के लिए भी खुले हैं, जो वास्तविक risk है। App Check + सही rules defense-in-depth pattern है।
क्या scanner मेरे फ़िक्स को verify कर सकता है?
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.
अगले कदम
अपने production URL के विरुद्ध एक मुफ़्त FixVibe scan चलाएँ — BaaS-phase checks मुफ़्त tier सहित हर plan पर ship होते हैं। Provider-specific deep-dives के लिए, इस section में व्यक्तिगत लेख हर provider को विस्तार से cover करते हैं: Supabase RLS, Supabase service-key exposure, Supabase storage, Firebase rules, Firebase if-true, Clerk, और Auth0।