סורק תצורות שגויות של BaaS: מצא נתיבי נתונים ציבוריים לפני שהמשתמשים יעשו זאת

מדוע לתצורות שגויות של BaaS יש צורה חוזרת

כל פלטפורמת BaaS עוקבת אחר אותו אדריכלות: backend מנוהל עם SDK לקוח דק שמדבר איתו מהדפדפן. הלקוח מול-הדפדפן צריך איזשהו אישור — מפתח anon, מפתח publishable, מזהה פרויקט Firebase — כדי לזהות את עצמו בפני ה-backend. האישור הזה ציבורי בכוונה; בטיחות האדריכלות נחה על בקרות גישה ברמת-פלטפורמה (RLS, חוקים, רשימות היתר) שעושות את עבודתן.

כלי קוד מבוססי-AI בונים על האדריכלות הזו מבלי להפנים את שכבת בקרות-הפלטפורמה. הם מחברים את ה-SDK של הלקוח נכון, מקבלים את חוקי ברירת המחדל המתירניים של הפלטפורמה (שקיימים לידידותיות-מדריך), ושולחים לייצור. הצורה החוזרת היא: אישור ציבורי + חוק ברירת מחדל מתירני + override חסר = חשיפת נתונים. חמש מחלקות התצורה השגויה למטה הן כולן וריאציות של הצורה הזו.

חמש מחלקות התצורה השגויה החוזרות

אלה מופיעות על פני כל ספק BaaS. סריקה מלאה מכסה את כל החמש מול כל ספק בשימוש:

מחלקה 1: מפתח שגוי בחבילת הדפדפן

הדפדפן שולח את המפתח הסודי/admin (Supabase service_role, מפתח פרטי של Firebase Admin SDK, Clerk sk_*, סוד לקוח של Auth0) במקום את המקבילה הציבורית/anon. הדפדפן הופך ללקוח admin בלתי-מוגבל. מכוסה על-ידי בדיקת bundle-secrets של FixVibe.

מחלקה 2: שכבת בקרת-גישה מושבתת או מתירנית

RLS כבוי, חוקי Firebase הם if true, רשימת ה-callback של Auth0 היא wildcarded. האישור בדפדפן הוא הנכון — אבל הגבול ברמת-הפלטפורמה שהיה אמור להגביל אותו לא עושה את עבודתו.

מחלקה 3: קריאות אנונימיות של משאבים רגישים

אוספי Firestore הניתנים לקריאה אנונימית, דליי אחסון Supabase הניתנים לרישום אנונימי, API ניהול של Auth0 הנגיש אנונימית. הסריקה שואלת: "ללא אישורים, מה אני יכול לקרוא?"

מחלקה 4: ארטיפקטים של מצב-בדיקה בייצור

מפתחות בדיקה (pk_test_*, sb_test_*) ב-deploy של ייצור; אפליקציות Firebase במצב-dev נגישות מהדומיין החי; אפליקציות Auth0 של דייר-בדיקה עם הגדרות חלשות יותר מהייצור. הסריקה משווה את מפתחות ה-runtime מול קידומות הייצור הצפויות.

מחלקה 5: אימות חתימת webhook חסר

Webhooks של Clerk, Stripe, ו-Supabase כולם חותמים על ה-payloads שלהם. handler שלא מאמת את החתימה הוא פרימיטיב לכתיבה למסד נתונים עבור כל תוקף שמנחש את ה-URL. מזוהה דרך צורת תגובה — בקשה לא-חתומה שמקבלת 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. שלב 2 — בחינות ספציפיות-לספק. עבור כל ספק שזוהה, הסורק מריץ את הבדיקה הספציפית-לספק: baas.supabase-rls בוחן PostgREST; baas.firebase-rules בוחן Firestore + RTDB + אחסון; baas.clerk-auth0 מאמת את הקידומת של מפתחות מצורפים; בדיקת ה-bundle-secrets מאמתת שאישורים בדרגת service לא דלפו. כל בחינה רצה עצמאית — ממצא Supabase לא חוסם את סריקת ה-Firebase.
3. שלב 3 — מתאם חוצה-ספקים. הסורק עושה הצלבה של ממצאים. מפתח Supabase service-role שדלף לצד RLS חסר חמור יותר מכל אחד מהממצאים לבד — הדוח מציף זאת. ריבוי ספקי זהויות (Clerk + Auth0 + אימות מותאם) באותה אפליקציה הוא ממצא מבני שמסומן לסקירה.

כל בחינה היא פסיבית: לכל היותר קריאה אנונימית אחת לכל משאב, עם צורת תגובה רשומה אבל תוכן שורות שלעולם לא מדפדף או מאוחסן. בחינות כתיבה ושינוי מוגבלות מאחורי אימות בעלות על דומיין — הן לעולם לא רצות מול מטרות לא-מאומתות.

מה הסורק מוצא לכל ספק

לכל ספק BaaS יש משטח שונה ואסטרטגיית סריקה שונה. הנה מה שמכוסה:

• Supabase: RLS חסר על טבלאות, דליי אחסון הניתנים לרישום אנונימי, JWT service_role שדלף או מפתח sb_secret_* בחבילה, סכמות חשופות דרך רישום OpenAPI אנונימי. ראה סורק Supabase RLS ו-רשימת בדיקה לאחסון.
• Firebase: חוקי if true על Firestore, Realtime Database, ו-Cloud Storage; דליי אחסון הניתנים לרישום אנונימי; אכיפת App Check חסרה. ראה סורק חוקי Firebase ו-הסבר חוק if-true.
• Clerk: מפתחות סוד sk_* מצורפים, pk_test_* בייצור, אימות חתימת webhook חסר, מקורות מותרים עם wildcard. ראה רשימת בדיקה ל-Clerk.
• Auth0: סודות לקוח מצורפים, grant של Implicit מופעל, callback / logout URLs עם wildcard, PKCE חסר ב-SPAs. ראה רשימת בדיקה ל-Auth0.

איך סורק BaaS משתווה לכלי DAST ו-SAST כלליים

סורק מודע-ל-BaaS עושה עבודה ספציפית שכלים אחרים לא עושים. ההשוואה:

היקף הוגן: מה הסורק הזה לא מחליף

סורק DAST מודע-ל-BaaS הוא כלי ממוקד, לא תוכנית אבטחה מלאה. הוא לא:

• מחליף SAST או SCA. ניתוח סטטי מוצא CVEs של תלויות (Snyk, Semgrep) ופגיעויות ברמת-קוד (SonarQube) שסורק DAST לא יכול. הרץ את שניהם.
• מחליף בדיקות חדירה ידניות. פנטסטר אנושי מוצא פגמי לוגיקה עסקית, מקרי קצה של הרשאה, ופגיעויות משורשרות שאף סורק לא יכול. שכור פנטסטר לפני השקה גדולה או audit תאימות.
• מבצע audit לקוד או למאגר שלך עבור סודות בהיסטוריית git. בדיקת ה-bundle-secrets מכסה את מה שפרוס כרגע, לא את מה שעבר commit היסטורי. השתמש ב-git-secrets או ב-gitleaks להיגיינת מאגר.
• מכסה שירותי backend שאינם BaaS. אם האפליקציה שלך משתמשת ב-backend מותאם (Express, Rails, Django, FastAPI), FixVibe סורק את משטח ה-HTTP שלו אבל לא בוחן את מסד הנתונים או התשתית מאחוריו. זה טריטוריית DAST + SAST כללית.

שאלות נפוצות

צעדים הבאים

הרץ סריקת FixVibe חינמית מול URL הייצור שלך — בדיקות שלב ה-BaaS נשלחות בכל תוכנית, כולל השכבה החינמית. לצלילות עומק ספציפיות-לספק, המאמרים האישיים בסעיף הזה מכסים כל ספק בפירוט: Supabase RLS, חשיפת מפתח service של Supabase, אחסון Supabase, חוקי Firebase, Firebase if-true, Clerk, ו-Auth0.