הקרס
אבטחת פרויקט Supabase דורשת גישה רב-שכבתית המתמקדת בניהול מפתחות API, אבטחת מסד נתונים והרשאות אחסון. [S1] מוגדר שגוי של אבטחת רמת שורה (RLS) או מפתחות רגישים חשופים עלולים להוביל לאירועי חשיפת נתונים משמעותיים. [S2] [S3]
מה השתנה
מחקר זה מאחד בקרות אבטחה הליבה עבור סביבות Supabase בהתבסס על הנחיות ארכיטקטורה רשמיות. [S1] הוא מתמקד במעבר מתצורות פיתוח ברירת מחדל לתנוחות מוקשחות בייצור, במיוחד לגבי מנגנוני בקרת גישה. [S2] [S3]
מי מושפע
אפליקציות המשתמשות ב-Supabase כ- Backend-as-a-Service (BaaS) מושפעות, במיוחד אלו המטפלות בנתונים ספציפיים למשתמש או בנכסים פרטיים. [S2] מפתחים שכוללים את מפתח service_role בחבילות בצד הלקוח או לא מצליחים להפעיל את RLS נמצאים בסיכון גבוה. [S1]
איך הבעיה עובדת
Supabase ממנפת את ה-Row Level Security של PostgreSQL כדי להגביל את הגישה לנתונים. [S2] כברירת מחדל, אם RLS אינו מופעל בטבלה, כל משתמש עם מפתח anon - שהוא לרוב ציבורי - יכול לגשת לכל הרשומות. [S1] באופן דומה, Supabase Storage דורש מדיניות מפורשת כדי להגדיר אילו משתמשים או תפקידים יכולים לבצע פעולות על דלי קבצים. [S3]
מה שתוקף מקבל
תוקף המחזיק מפתח API ציבורי יכול לנצל טבלאות חסרות RLS כדי לקרוא, לשנות או למחוק נתונים השייכים למשתמשים אחרים. [S1] [S2] גישה לא מורשית לדלי אחסון עלולה להוביל לחשיפה של קבצי משתמש פרטיים או למחיקת נכסי אפליקציה קריטיים. [S3]
כיצד FixVibe בודק את זה
FixVibe מכסה זאת כעת כחלק מבדיקות ה-Supabase שלו. baas.supabase-security-checklist-backfill סוקרת Supabase מטא נתונים ציבוריים של דלי אחסון, חשיפה אנונימית של רישום אובייקטים, שמות של דלי רגישים, ואותות אחסון בלתי קשורים מגבול האנון הציבורי. בדיקות חיות קשורות בודקות חשיפת מפתח תפקידי שירות, תנוחת Supabase REST/RLS והעברת SQL של מאגר עבור RLS חסרים.
מה לתקן
הפעל תמיד אבטחה ברמת שורה בטבלאות מסד נתונים והטמיע מדיניות מפורטת עבור משתמשים מאומתים. [S2] ודא שרק מפתח 'אנון' משמש בקוד בצד הלקוח, בעוד שמפתח 'service_role' נשאר בשרת. [S1] הגדר את בקרת גישה לאחסון כדי להבטיח שדלי קבצים הם פרטיים כברירת מחדל והגישה ניתנת רק באמצעות מדיניות אבטחה מוגדרת. [S3]