اسکنر پیکربندی نادرست BaaS: یافتن مسیرهای داده عمومی پیش از کاربران

چرا پیکربندی‌های نادرست BaaS یک شکل تکراری دارند

هر پلتفرم BaaS از همان معماری پیروی می‌کند: یک بک‌اند مدیریت‌شده با یک SDK کلاینت نازک که از مرورگر با آن صحبت می‌کند. کلاینت client-facing به یک اعتبارنامه نیاز دارد — یک کلید anon، یک کلید publishable، یک شناسه پروژه Firebase — تا خود را به بک‌اند معرفی کند. آن اعتبارنامه به‌طور عمدی عمومی است؛ ایمنی معماری به کنترل‌های دسترسی در سطح پلتفرم (RLS، قواعد، allowlistها) که کار خود را انجام می‌دهند تکیه دارد.

ابزارهای کدنویسی هوش مصنوعی روی این معماری می‌سازند بدون این‌که لایه کنترل‌های پلتفرم را درونی کنند. آن‌ها SDK کلاینت را درست پیکربندی می‌کنند، قواعد پیش‌فرض بازگذاشته پلتفرم را می‌پذیرند (که برای دوستی با آموزش وجود دارند)، و منتشر می‌کنند. شکل تکراری این است: اعتبارنامه عمومی + قانون پیش‌فرض بازگذاشته + override گم‌شده = افشای داده. پنج کلاس پیکربندی نادرست زیر همگی گونه‌هایی از این شکل هستند.

پنج کلاس پیکربندی نادرست تکراری

این‌ها در سراسر هر ارائه‌دهنده BaaS ظاهر می‌شوند. یک اسکن کامل هر پنج را در برابر هر ارائه‌دهنده مورد استفاده پوشش می‌دهد:

کلاس ۱: کلید اشتباه در بسته مرورگر

مرورگر کلید secret/admin (Supabase service_role، کلید خصوصی Firebase Admin SDK، Clerk sk_*، client secret Auth0) را به‌جای معادل عمومی/anon می‌فرستد. مرورگر تبدیل به یک کلاینت admin بدون محدودیت می‌شود. توسط فحص bundle-secrets FixVibe پوشش داده می‌شود.

کلاس ۲: لایه کنترل دسترسی غیرفعال یا بازگذاشته

RLS خاموش است، قواعد Firebase if true هستند، فهرست callback Auth0 wildcard است. اعتبارنامه در مرورگر درست است — ولی مرز سطح پلتفرم که قرار بود آن را محدود کند کار خود را انجام نمی‌دهد.

کلاس ۳: خواندن‌های ناشناس از منابع حساس

مجموعه‌های Firestore قابل خواندن توسط anon، سطل‌های ذخیره‌سازی Supabase قابل فهرست توسط anon، API مدیریت Auth0 قابل دسترسی توسط anon. اسکن می‌پرسد: "بدون اعتبارنامه، چه چیزی را می‌توانم بخوانم؟"

کلاس ۴: آثار حالت آزمایشی در تولید

کلیدهای آزمایشی (pk_test_*، sb_test_*) در یک استقرار تولید؛ اپلیکیشن‌های Firebase dev-mode قابل دسترسی از دامنه زنده؛ اپلیکیشن‌های مستأجر آزمایشی Auth0 با تنظیمات ضعیف‌تر از تولید. اسکن کلیدهای زمان اجرا را در برابر پیشوندهای تولید مورد انتظار مقایسه می‌کند.

کلاس ۵: تأیید امضای webhook گم‌شده

webhookهای Clerk، webhookهای Stripe، webhookهای Supabase همگی payloadهای خود را امضا می‌کنند. یک handler که امضا را تأیید نمی‌کند یک ابزار اولیه نوشتن در پایگاه‌داده برای هر مهاجمی که URL را حدس می‌زند است. از طریق شکل پاسخ تشخیص داده می‌شود — یک درخواست unsigned که 200 می‌گیرد یعنی تأیید رد شده است.

اسکن چتری BaaS در FixVibe چگونه کار می‌کند

فاز BaaS در FixVibe در سه مرحله اجرا می‌شود، هر یک یافته‌های متمایز تولید می‌کند:

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. مرحله ۲ — پروب‌های اختصاصی ارائه‌دهنده. برای هر ارائه‌دهنده شناسایی‌شده، اسکنر فحص اختصاصی ارائه‌دهنده را اجرا می‌کند: baas.supabase-rls PostgREST را پروب می‌کند؛ baas.firebase-rules Firestore + RTDB + Storage را پروب می‌کند؛ baas.clerk-auth0 پیشوند کلیدهای بسته‌بندی‌شده را اعتبارسنجی می‌کند؛ فحص bundle-secrets اعتبارسنجی می‌کند که هیچ اعتبارنامه سطح service نشت نکرده باشد. هر پروب به‌صورت مستقل اجرا می‌شود — یک یافته Supabase اسکن Firebase را مسدود نمی‌کند.
3. مرحله ۳ — همبستگی cross-provider. اسکنر یافته‌ها را cross-reference می‌کند. یک کلید service-role Supabase نشت‌یافته در کنار RLS گم‌شده شدیدتر از هر یافته به‌تنهایی است — گزارش این را نشان می‌دهد. ارائه‌دهندگان هویت چندگانه (Clerk + Auth0 + احراز هویت سفارشی) در یک اپلیکیشن یک یافته ساختاری است که برای بررسی علامت‌گذاری می‌شود.

هر پروب غیرفعال است: حداکثر یک خواندن ناشناس به‌ازای هر منبع، با شکل پاسخ ثبت‌شده ولی محتوای ردیف هرگز صفحه‌بندی یا ذخیره نشده. پروب‌های نوشتن و تغییر پشت تأیید مالکیت دامنه قفل شده‌اند — هرگز روی اهداف تأییدنشده اجرا نمی‌شوند.

اسکنر به‌ازای هر ارائه‌دهنده چه چیزی پیدا می‌کند

هر ارائه‌دهنده BaaS یک سطح متفاوت و یک استراتژی اسکن متفاوت دارد. آنچه پوشش داده شده:

• Supabase: RLS گم‌شده روی جدول‌ها، سطل‌های ذخیره‌سازی قابل فهرست توسط anon، JWT service_role یا کلید sb_secret_* نشت‌یافته در بسته، اسکیماهای افشاشده از طریق فهرست OpenAPI ناشناس. اسکنر Supabase RLS و چک‌لیست ذخیره‌سازی را ببینید.
• Firebase: قواعد if true روی Firestore، Realtime Database و Cloud Storage؛ سطل‌های Storage قابل فهرست توسط anon؛ اعمال App Check گم‌شده. اسکنر قوانین Firebase و توضیح قانون if-true را ببینید.
• Clerk: کلیدهای secret sk_* بسته‌بندی‌شده، pk_test_* در تولید، تأیید امضای webhook گم‌شده، originهای مجاز wildcard. چک‌لیست Clerk را ببینید.
• Auth0: client secretهای بسته‌بندی‌شده، grant Implicit فعال، URLهای callback / logout با wildcard، PKCE گم‌شده روی SPAها. چک‌لیست Auth0 را ببینید.

یک اسکنر BaaS چگونه با ابزارهای DAST و SAST عمومی مقایسه می‌شود

یک اسکنر BaaS-aware کار خاصی انجام می‌دهد که سایر ابزارها انجام نمی‌دهند. مقایسه:

محدوده صادقانه: این اسکنر چه چیزی را جایگزین نمی‌کند

یک اسکنر DAST آگاه از BaaS یک ابزار متمرکز است، نه یک برنامه امنیتی کامل. این کار را نمی‌کند:

• جایگزین SAST یا SCA. تحلیل ایستا CVEهای وابستگی (Snyk، Semgrep) و آسیب‌پذیری‌های سطح کد (SonarQube) را پیدا می‌کند که یک اسکنر DAST نمی‌تواند. هر دو را اجرا کنید.
• جایگزین تست نفوذ دستی. یک پن‌تستر انسانی نقص‌های منطق کسب‌وکار، موارد لبه مجوزدهی و آسیب‌پذیری‌های زنجیره‌شده را پیدا می‌کند که هیچ اسکنری نمی‌تواند. یک پن‌تستر را پیش از یک راه‌اندازی بزرگ یا ممیزی انطباق استخدام کنید.
• ممیزی کد یا ریپو برای اسرار در تاریخچه git. فحص bundle-secrets آنچه در حال حاضر مستقر شده را پوشش می‌دهد، نه آنچه از نظر تاریخی commit شده. از git-secrets یا gitleaks برای بهداشت ریپو استفاده کنید.
• پوشش سرویس‌های بک‌اند غیر-BaaS. اگر اپلیکیشن شما از یک بک‌اند سفارشی استفاده می‌کند (Express، Rails، Django، FastAPI)، FixVibe سطح HTTP آن را اسکن می‌کند ولی پایگاه‌داده یا زیرساخت پشت آن را پروب نمی‌کند. این قلمرو DAST + SAST عمومی است.

سؤالات متداول

گام‌های بعدی

یک اسکن رایگان FixVibe را روی URL تولیدی خود اجرا کنید — فحص‌های فاز BaaS روی هر پلن، از جمله پلن رایگان، ارائه می‌شوند. برای deep-diveهای اختصاصی ارائه‌دهنده، مقاله‌های فردی در این بخش هر ارائه‌دهنده را به‌تفصیل پوشش می‌دهند: Supabase RLS، افشای کلید-سرویس Supabase، ذخیره‌سازی Supabase، قوانین Firebase، Firebase if-true، Clerk و Auth0.