// 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-এর নিরাপত্তা platform-level access controls (RLS, rules, allowlists) তাদের কাজ করার উপর নির্ভর করে।
AI কোডিং টুলগুলি platform-controls layer অভ্যন্তরীণ না করেই এই architecture-এর উপর build করে। তারা client SDK সঠিকভাবে wire করে, platform-এর default permissive rules গ্রহণ করে (যা tutorial-friendliness-এর জন্য বিদ্যমান), এবং ship করে। পুনরাবৃত্ত আকার হল: public credential + permissive default rule + অনুপস্থিত override = data exposure। নিচের পাঁচটি misconfiguration classes সবই এই আকারের রূপ।
পাঁচটি পুনরাবৃত্ত 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 off, Firebase rules if true, Auth0 callback list wildcarded। Browser-এ credential সঠিক — কিন্তু platform-level boundary যা এটিকে সীমাবদ্ধ করার উদ্দেশ্যে ছিল তা তার কাজ করছে না।
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 অ্যাপ; production-এর চেয়ে দুর্বল settings সহ test-tenant Auth0 applications। Scan runtime keys-কে প্রত্যাশিত production prefixes-এর বিরুদ্ধে তুলনা করে।
Class 5: Webhook signature verification অনুপস্থিত
Clerk webhooks, Stripe webhooks, Supabase webhooks সব তাদের payloads sign করে। একটি handler যে signature যাচাই করে না সেটি যেকোনো আক্রমণকারীর জন্য যে URL অনুমান করে একটি database-write primitive। Response shape-এর মাধ্যমে detected — একটি unsigned request যে একটি 200 পায় মানে যাচাই skipped।
FixVibe umbrella BaaS scan কীভাবে কাজ করে
FixVibe-এর BaaS phase তিনটি stages-এ চলে, প্রতিটি স্বতন্ত্র findings তৈরি করে:
- <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.
- Stage 2 — provider-specific probes। প্রতিটি detected provider-এর জন্য, scanner provider-specific check চালায়:
baas.supabase-rlsPostgREST probe করে;baas.firebase-rulesFirestore + RTDB + Storage probe করে;baas.clerk-auth0bundled keys-এর prefix validate করে; bundle-secrets check validate করে যে কোনো service-tier credentials leak হয়নি। প্রতিটি probe স্বাধীনভাবে চলে — একটি Supabase finding Firebase scan ব্লক করে না। - Stage 3 — cross-provider correlation। Scanner findings cross-reference করে। অনুপস্থিত RLS-এর পাশাপাশি একটি leaked Supabase service-role key যেকোনো একটি finding-এর চেয়ে বেশি গুরুতর — report এটি surface করে। একই অ্যাপে একাধিক identity providers (Clerk + Auth0 + custom auth) পর্যালোচনার জন্য flagged একটি structural finding।
প্রতিটি probe passive: per resource সর্বাধিক একটি anonymous read, response shape record করা কিন্তু row contents কখনো paginated বা stored নয়। 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-aware DAST) | General DAST (Burp / ZAP) | SAST / SCA (Snyk / Semgrep) |
|---|---|---|---|
| BaaS কভারেজ | Supabase, Firebase, Clerk, Auth0, Appwrite-এর জন্য native checks | Generic web crawl; কোনো provider-specific probes নেই | শুধুমাত্র repo-এর Static analysis; কোনো production validation নেই |
| Setup time | URL → run → 60 সেকেন্ডে results | ঘণ্টা: spider, auth, scope configure করুন | দিন: repo CI-তে integrate করুন |
| এটি কী প্রমাণ করে | HTTP-level evidence সহ Production-runtime exposure | Web-app vulns (XSS, SQLi); manual config-এর মাধ্যমে BaaS | Code patterns যা deploy হতে পারে বা নাও পারে |
| JavaScript bundle inspection | JWTs decode করে, secret prefixes match করে, chunks walk করে | সীমিত — শুধুমাত্র string-based grep | হ্যাঁ, কিন্তু শুধুমাত্র repo-side, deployed নয় |
| Continuous scanning | API + MCP-এর মাধ্যমে মাসিক / on-deploy | Manual; নিজে schedule configure করুন | Per-commit (code-এর জন্য ভাল, runtime-এ blind) |
| একক / ছোট team-এর জন্য মূল্য | ফ্রি tier; paid $19/মাস থেকে | Burp Pro $499/বছর; ZAP ফ্রি কিন্তু উচ্চ false positives | Snyk free / Semgrep free; paid tiers $25/dev থেকে |
Honest scope: এই scanner কী প্রতিস্থাপন করে না
একটি BaaS-aware DAST scanner একটি কেন্দ্রীভূত টুল, একটি সম্পূর্ণ security program নয়। এটি করে না:
- SAST বা SCA প্রতিস্থাপন। Static analysis dependency CVEs (Snyk, Semgrep) এবং code-level vulnerabilities (SonarQube) খুঁজে পায় যা একটি DAST scanner পারে না। উভয়ই চালান।
- Manual penetration testing প্রতিস্থাপন। একজন human pentester business-logic flaws, authorization edge cases, এবং chained vulnerabilities খুঁজে পায় যা কোনো scanner পারে না। একটি বড় launch বা compliance audit-এর আগে একজন pentester ভাড়া করুন।
- git history-তে secrets-এর জন্য আপনার code বা repo audit করুন। Bundle-secrets check বর্তমানে যা deployed তা cover করে, ঐতিহাসিকভাবে যা committed ছিল তা নয়। Repo hygiene-এর জন্য
git-secretsবাgitleaksব্যবহার করুন। - non-BaaS backend services cover। যদি আপনার অ্যাপ একটি custom backend (Express, Rails, Django, FastAPI) ব্যবহার করে, FixVibe এর HTTP পৃষ্ঠ scan করে কিন্তু এর পিছনে database বা infrastructure probe করে না। সেটি general DAST + SAST territory।
প্রায়শই জিজ্ঞাসিত প্রশ্ন
আমার অ্যাপ দুটি BaaS providers (যেমন, Supabase + Clerk) ব্যবহার করলে umbrella scan কি কাজ করে?
হ্যাঁ — provider fingerprinting এবং per-provider probes স্বাধীন। Scanner উভয়ই detect করে, উভয় check suites চালায়, এবং cross-provider correlations রিপোর্ট করে (যেমন, Clerk থেকে একটি Supabase JWT template যা অনুপস্থিত RLS-এর পাশাপাশি একটি claim হিসাবে email ship করে)।
এটি আমার অ্যাপের বিরুদ্ধে Burp Suite Pro চালানোর থেকে কীভাবে আলাদা?
Burp একটি general DAST workbench। Out of the box, Burp জানে না PostgREST, Firestore, বা Auth0 callback path কী — আপনাকে manually scope configure করতে হবে, extensions লিখতে হবে, এবং responses interpret করতে হবে। FixVibe built-in BaaS probes এবং BaaS-shaped evidence formatting সহ ship করে। Burp general web-app coverage (XSS, SQLi, business logic)-এ জিতে; FixVibe BaaS-specific findings-এ জিতে।
App Check (Firebase) বা attestation (Apple / Google) সম্পর্কে কী?
App Check opportunistic external scans-কে প্রতিটি probe-এ 403 return করায় — একটি ক্ষতিকারক bot-এর জন্য সঠিক outcome। একটি unattested client থেকে একটি FixVibe scan একইভাবে আচরণ করে। যদি আপনার App Check enabled থাকে এবং FixVibe এখনো findings রিপোর্ট করে, এর মানে আপনার rules attested clients-এর জন্যও খোলা, যা প্রকৃত ঝুঁকি। App Check + সঠিক rules হল defense-in-depth pattern।
scanner কি আমার fix যাচাই করতে পারে?
হ্যাঁ — fix প্রয়োগ করার পরে পুনরায় চালান। Check IDs (যেমন, baas.supabase-rls) runs জুড়ে stable, তাই আপনি findings diff করতে পারেন: একটি finding যা run 1-এ open ছিল এবং run 2-এ অনুপস্থিত fix landed-এর প্রমাণ।
পরবর্তী পদক্ষেপ
আপনার production URL-এর বিরুদ্ধে একটি ফ্রি FixVibe scan চালান — BaaS-phase checks ফ্রি tier সহ প্রতিটি plan-এ ship হয়। Provider-specific deep-dives-এর জন্য, এই বিভাগের পৃথক প্রবন্ধগুলি প্রতিটি provider বিস্তারিতভাবে cover করে: Supabase RLS, Supabase service-key exposure, Supabase storage, Firebase rules, Firebase if-true, Clerk, এবং Auth0।