הרשאות: יש התחברות, אבל הנתונים מוגנים?

הרשאות: ההבדל בין "יש התחברות" לבין "הנתונים מוגנים"#

Authentication — אימות זהות עונה על "מי זה?"; Authorization — הרשאה עונה על "מה מותר לו לעשות, על איזה משאב ובאיזה מצב?". מערכת יכולה להציג מסך התחברות יפה ועדיין לחשוף מידע של לקוח אחד ללקוח אחר. הסתרת כפתור בממשק אינה מחסום אבטחה.

דרישת בסיס: אכיפה בצד שהמשתמש אינו שולט בו#

בקשות יש לבדוק בצד שרת או במנגנון הרשאות אוכף ברמת מסד הנתונים; אין לסמוך על מזהה לקוח שמגיע מהדפדפן בלי לקשור אותו לזהות מאומתת. הרשאות אינן רק קריאה — יש לבדוק יצירה, עריכה, מחיקה, הורדה ופעולות חריגות. כשיש ארגונים/לקוחות שונים (multi-tenancy) יש לוודא בידוד רוחבי: בעלות המשאב, חברות בארגון ותפקידו של המשתמש.

מה רלוונטי ל-Supabase, ומה לא#

ב-Supabase מנגנון PostgreSQL Row Level Security (RLS) מאפשר להגדיר מדיניות גישה ברמת שורה. אבל "RLS מופעל" אינו שקול ל"הנתונים מאובטחים". יש לבדוק גם grants לתפקידים, מדיניות לכל פעולה, views, פונקציות, תרחישי שירות עם הרשאות גבוהות, והשלכות של מפתחות שרת. לפי התיעוד הרשמי, service_role או מפתח secret מתאים עשויים לעקוף RLS בתנאים מוגדרים; הם אינם מיועדים לדפדפן. תיעוד Supabase מפרט כיצד לבדוק בפועל גם גישה מותרת וגם גישה אסורה. מקור: Supabase RLS.

סודות ומפתחות#

מפתח API סודי, אסימון שירות או הרשאת מנהל אינם אמורים להופיע בקוד לקוח שנשלח לדפדפן, בקובצי Git, בצילום מסך או בלוגים גלויים. מפתח ציבורי שמיועד לשימוש בצד לקוח אינו בהכרח סוד, אבל הוא מחייב מנגנון הרשאות נוסף שמגן על הנתונים. יש לנהל סודות בסביבה מוגנת, לצמצם את ההרשאות שלהם, לדעת כיצד מסובבים מפתח שנחשף ולמנוע הופעתו בהיסטוריית גרסאות. מקור: OWASP Secrets Management.

איך בודקים באמת#

השתמשו בזהויות בדיקה נפרדות ובנתוני בדיקה שאינם רגישים. בדקו לא רק מה מוצג בממשק אלא גם האם API מאפשר לגשת למשאב שלא שייך למשתמש. כל ניסיון אמור להיבדק בסביבה ובחשבונות שבהם יש לכם הרשאה לבצע בדיקות. דרשו תוצאות מפורשות עבור משתמש אורח, משתמש רגיל, בעל הרשאה מורחבת ומנהל. אם אינכם יודעים מי יכול לקרוא או לשנות רשומה — אל תפתחו אותה לציבור.