BaaS misconfiguration scanner: users से पहले public data paths ढूँढ़ें

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 सभी अपने payloads को sign करते हैं। एक handler जो signature verify नहीं करता, किसी भी हमलावर के लिए database-write primitive है जो URL का अनुमान लगाता है। Response shape के माध्यम से detected — एक unsigned request जो 200 प्राप्त करती है का मतलब verification skipped है।

FixVibe umbrella BaaS scan कैसे काम करता है

FixVibe का BaaS phase तीन चरणों में चलता है, हर एक विशिष्ट findings उत्पन्न करता है:

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. चरण 2 — provider-specific probes. हर detected provider के लिए, scanner provider-specific check चलाता है: baas.supabase-rls PostgREST को probe करता है; baas.firebase-rules Firestore + RTDB + Storage को probe करता है; baas.clerk-auth0 bundled keys के prefix को validate करता है; bundle-secrets check validate करता है कि कोई service-tier credentials leak नहीं हुई। हर probe स्वतंत्र रूप से चलती है — एक Supabase finding Firebase scan को block नहीं करती।
3. चरण 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_role JWT या sb_secret_* key, anonymous OpenAPI listing के माध्यम से exposed schemas। Supabase RLS scanner और Storage checklist देखें।
• Firebase: Firestore, Realtime Database, और Cloud Storage पर if true rules; 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 नहीं करते। तुलना:

ईमानदार scope: यह scanner क्या replace नहीं करता

एक BaaS-aware DAST scanner एक केंद्रित टूल है, एक पूर्ण security program नहीं। यह नहीं करता:

• SAST या SCA को Replace करें। Static analysis dependency CVEs (Snyk, Semgrep) और code-level vulnerabilities (SonarQube) ढूँढ़ता है जो एक DAST scanner नहीं कर सकता। दोनों चलाएँ।
• Manual penetration testing को Replace करें। एक मानव pentester business-logic flaws, authorization edge cases, और chained vulnerabilities ढूँढ़ता है जो कोई scanner नहीं ढूँढ़ सकता। एक प्रमुख launch या compliance audit से पहले एक pentester को hire करें।
• git history में secrets के लिए अपने कोड या repo का audit करें। Bundle-secrets check वर्तमान में जो deployed है उसे cover करता है, ऐतिहासिक रूप से जो committed था वह नहीं। Repo hygiene के लिए git-secrets या gitleaks का उपयोग करें।
• Non-BaaS backend services को Cover करें। यदि आपकी app एक custom backend (Express, Rails, Django, FastAPI) का उपयोग करती है, FixVibe इसकी HTTP surface को scan करता है पर इसके पीछे database या infrastructure को probe नहीं करता। यह सामान्य DAST + SAST territory है।

अक्सर पूछे जाने वाले प्रश्न

अगले कदम

अपने 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।