// docs / baas security
BaaS सुरक्षा
Backend-as-a-Service प्लेटफ़ॉर्म — Supabase, Firebase, Clerk, Auth0 — ऐप के उन हिस्सों को संभालते हैं जिन्हें AI कोडिंग टूल सबसे कम सावधानी से छूते हैं: row-level security, storage rules, identity provider कॉन्फ़िगरेशन, और कौन-सी keys browser को भेजी जाती हैं। यह सेक्शन एक केंद्रित लेख-पुस्तकालय है कि ये गलत कॉन्फ़िगरेशन प्रोडक्शन में वास्तव में कैसी दिखती हैं और इन्हें कैसे ढूँढ़ें और ठीक करें। हर लेख आपके अपने deployment के एक-क्लिक scan के साथ समाप्त होता है।
// supabase rls scanner
Supabase RLS scanner: गायब या टूटी हुई row-level security वाली tables ढूँढ़ें
एक passive RLS scan database के बाहर से क्या साबित कर सकता है, AI कोडिंग टूल डिफ़ॉल्ट रूप से जो चार आकार की टूटी RLS बनाते हैं, FixVibe का
baas.supabase-rlscheck कैसे काम करता है, और जब कोई गायब policy मिले तो लागू करने के लिए सटीक SQL।अपनी app में गायब RLS के लिए scan करें →
// service role key exposure
JavaScript में Supabase service role key उजागर
Service role key क्या है, यह browser में क्यों कभी नहीं रहनी चाहिए, और AI कोडिंग टूल इसे production में ship करने के तीन तरीके। JWT shape जो leaked key की पहचान करता है, एक तत्काल-प्रतिक्रिया runbook, और FixVibe bundle scan इसे कैसे पकड़ता है, सम्मिलित है।
जाँचें कि आपके bundle में secrets ship हुए हैं या नहीं →
// storage hardening
Supabase storage bucket security checklist
Supabase Storage को hardening करने के लिए एक केंद्रित 22-आइटम checklist — bucket visibility,
objectstable पर RLS policies, MIME-type validation, signed-URL handling, anti-enumeration उपाय, और operational hygiene। प्रत्येक आइटम एक ऐसा आइटम है जिसे आप 5-15 मिनट में पूरा कर सकते हैं।Public buckets और anon-listable storage scan करें →
// firebase rules scanner
Firebase rules scanner: खुले Firestore, Realtime Database, और Storage rules ढूँढ़ें
एक Firebase rules scanner बाहर से कैसे काम करता है, AI टूल जो test-mode patterns generate करते हैं, तीन Firebase services जिनमें से प्रत्येक को अपने rule audit की आवश्यकता है (Firestore, Realtime Database, Storage), और एक scan बिना credentials के क्या साबित कर सकता है।
खुले read/write rules के लिए check करें →
// rule syntax explainer
Firebase allow read, write: if true समझाया गया
allow read, write: if true;rule वास्तव में क्या करता है, Firebase इसे test-mode default के रूप में क्यों ship करता है, एक हमलावर को क्या behaviour दिखता है, और इसे production-safe rule से replace करने के चार तरीके। एक copy-paste audit query और एक पाँच-step remediation plan सम्मिलित है।अपने production URL को scan करें →
// clerk hardening
Clerk security checklist
एक Clerk integration को harden करने के लिए 20-आइटम checklist — environment-key hygiene, session settings, webhook verification, organization permissions, JWT-template scoping, और operational monitoring। क्षेत्र के अनुसार group किए गए Pre-launch और ongoing आइटम।
Auth/session misconfigurations check करें →
// auth0 hardening
Auth0 security checklist
एक 22-आइटम Auth0 audit जो application type और grants, callback / logout URL allowlists, refresh-token rotation, custom-action security, RBAC और resource servers, anomaly detection, और tenant log monitoring को cover करता है। उन आइटमों को पकड़ता है जिन्हें AI-generated SaaS apps लगातार miss करते हैं।
Identity-provider exposure check करें →
// umbrella scanner
BaaS misconfiguration scanner: Supabase, Firebase, Clerk, और Auth0 में public data paths ढूँढ़ें
BaaS providers समान आकार में security में क्यों fail होते हैं, हर BaaS-समर्थित app को audit करनी चाहिए ऐसी पाँच misconfiguration classes, FixVibe umbrella BaaS scan सभी चार providers में कैसे काम करता है, हर scanner क्या साबित कर सकता है इसकी side-by-side comparison, और Burp, ZAP, और SAST tools की एक ईमानदार तुलना।
Users से पहले public data paths ढूँढ़ें →
आगे क्या आ रहा है
जैसे-जैसे FixVibe scan engine अपनी कवरेज बढ़ाता है, अधिक BaaS-केंद्रित लेख यहाँ आते जाएँगे। scan-engine changelog हर नई detection को दर्ज करता है — FixVibe अब बाहर से क्या साबित कर सकता है, इसके चालू बही-खाते के लिए इसकी सदस्यता लें।