השפעה
תוקפים יכולים לעקוף את היגיון היישום כדי לקרוא, לעדכן או למחוק רשומות במסד הנתונים אם אבטחת רמת השורה (RLS) אינה נאכפת כראוי [S1]. לעתים קרובות זה גורם לחשיפה של מידע אישי מזהה (PII) או נתוני יישומים רגישים למשתמשים שיש להם גישה רק למפתח האנונימי הציבורי API.
סיבת שורש
Supabase משתמש ב-Postgres Row Level Security כדי לנהל גישה לנתונים ברמת מסד הנתונים, שהוא בסיסי לאבטחת נתונים [S1]. בסביבת Next.js, מפתחים חייבים ליצור לקוח Supabase המטפל בצורה נכונה בקובצי Cookie והפעלות כדי לשמור על אבטחה במהלך עיבוד [S2] בצד השרת. פגיעויות מתעוררות בדרך כלל כאשר:
- טבלאות נוצרות ללא מופעלת RLS, מה שהופך אותן לנגישות באמצעות מפתח האנון הציבורי [S1].
- לקוח Supabase מוגדר בצורה שגויה ב-Next.js, ולא מצליח להעביר כראוי אסימוני אימות משתמש למסד הנתונים [S2].
- מפתחים משתמשים בטעות במפתח
service_roleבקוד בצד הלקוח, אשר עוקף את כל מדיניות RLS [S1].
תיקוני בטון
- הפעל את RLS: ודא ש-Row Level Security מופעל עבור כל טבלה במסד הנתונים Supabase שלך [S1].
- הגדר מדיניות: צור מדיניות Postgres ספציפית עבור
SELECT,INSERT,UPDATEו-DELETEפעולות כדי להגביל את הגישה בהתבסס על UID ZXCVIXZVICV של המשתמש. - השתמש בלקוחות SSR: הטמיע את חבילת
@supabase/ssrכדי ליצור לקוחות ב-Next.js המנהלים בצורה נכונה את האימות בצד השרת ואת עמידות הפגישה [S2].
כיצד FixVibe בודק את זה
FixVibe כבר מכסה זאת באמצעות בדיקות אפליקציות פרוסות ו-repo. המודול הפאסיבי baas.supabase-rls מגלה צמדי URL של Supabase וצמדי מפתח אנונימיים מחבילות JavaScript מאותו מקור, מבקש מ-PostgREST מטא נתונים של טבלה ציבורית, ומבצע בחירות מוגבלות לקריאה בלבד כדי לאשר חשיפת נתונים אנונימית מבלי לשנות את נתוני הלקוחות. סריקות ריפו מרצות גם את repo.supabase.missing-rls כדי לסמן העברות SQL היוצרות טבלאות ציבוריות ללא ENABLE ROW LEVEL SECURITY, וסריקות סודיות מחפשות חשיפת מפתח תפקיד שירות לפני שהיא מגיעה לדפדפן.