תשובה קצרה: מ-30 באוקטובר 2026 Supabase מחילה על כל הפרויקטים הקיימים שינוי שכבר חל על פרויקטים חדשים מאמצע השנה: טבלה חדשה ב-schema הציבורי לא מקבלת יותר הרשאות אוטומטיות ל-Data API. אם הוספתם פיצ'ר עם טבלה חדשה אחרי התאריך הזה, האפליקציה תקבל שגיאה 42501 עם הנוסח
permission denied for table, גם אם הכול נראה תקין. התיקון הואGRANTמפורש לתפקידים שצריכים את הטבלה, ורק אחרי שבדקתם ש-RLS מופעל עליה ומגן עליה.
מה השתנה ב-30.10.2026?
עד עכשיו, כל טבלה שנוצרה ב-schema public קיבלה מעצמה הרשאות קריאה, כתיבה, עדכון ומחיקה לשלושה תפקידים: anon, authenticated ו-service_role. זה מה שאפשר לאפליקציה לפנות לטבלה דרך supabase-js מהרגע שנוצרה.
לפי ההודעה הרשמית של Supabase, ההרשאות האוטומטיות האלה בוטלו. בפרויקטים חדשים זה ברירת המחדל מ-30.5.2026, ובפרויקטים קיימים זה נאכף מ-30.10.2026. שלושה דברים חשוב לדעת:
- טבלאות שכבר היו קיימות ממשיכות לעבוד. הן שומרות את ההרשאות שהיו להן.
- כל טבלה חדשה צריכה הרשאה מפורשת, כולל ל-
service_role, שמשמש את הפונקציות בצד השרת. - חיבור ישיר ל-Postgres לא מושפע. עורך ה-SQL, psql או ORM עם connection string ממשיכים לעבוד, ולכן הבעיה מופיעה רק מתוך האפליקציה.
איך זה נראה אצלכם?
הוספתם פיצ'ר באפליקציה שנבנתה ב-Lovable, Base44 או Bolt. הכלי יצר טבלה חדשה, הקוד נראה נכון, ובכל זאת המסך החדש לא נטען או שהשמירה נכשלת. בלשונית Network בכלי הפיתוח, הבקשה לנתיב /rest/v1/ חוזרת עם שגיאה כזו, ולצידה רמז עם פקודת ה-GRANT שחסרה:
{
"code": "42501",
"message": "permission denied for table your_table"
}
השגיאה לא מגיעה מ-RLS. היא אומרת שלתפקיד שפונה לטבלה אין הרשאה לגעת בה בכלל, עוד לפני שבודקים אילו שורות מותר לו לראות. אם המצב שלכם הוא מערך ריק בלי שגיאה, זו כנראה בעיית מדיניות, והפירוט נמצא במדריך ל-RLS שלא עובד ב-Supabase.
איך מוצאים את כל הטבלאות שחסרה להן הרשאה?
בעורך ה-SQL של Supabase הריצו:
select c.relname as table_name,
has_table_privilege('authenticated', c.oid, 'select') as authenticated_can_read,
has_table_privilege('service_role', c.oid, 'insert') as server_can_write,
c.relrowsecurity as rls_on
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind = 'r'
order by 2, 3;
כל שורה עם false בעמודה השנייה או השלישית היא טבלה שהאפליקציה או השרת לא יכולים לגשת אליה. גם ה-Security Advisor בלוח של Supabase מסמן טבלאות כאלה.
איך מתקנים בלי לפתוח את הנתונים לכולם?
הסדר חשוב. קודם RLS, אחר כך הרשאה.
1. ודאו ש-RLS מופעל ושיש מדיניות
alter table public.your_table enable row level security;
create policy "Users read their own rows"
on public.your_table for select
to authenticated
using (user_id = (select auth.uid()));
את המדיניות מתאימים למה שהטבלה מחזיקה: מי צריך לקרוא, מי כותב, ומי מעדכן. לכתיבה מוסיפים with check, כדי שמשתמש לא יוכל לכתוב שורה בשם מישהו אחר.
2. תנו הרשאה רק לתפקידים שצריכים אותה
-- משתמשים מחוברים שקוראים וכותבים מהדפדפן (RLS מגביל אילו שורות)
grant select, insert, update, delete on table public.your_table to authenticated;
-- פונקציות בצד השרת שעובדות עם service_role
grant select, insert, update, delete on table public.your_table to service_role;
תנו רק את הפעולות שבאמת צריך. טבלה שרק השרת כותב אליה, למשל טבלת הזמנות שנכתבת מתוך webhook של תשלום, צריכה הרשאת כתיבה ל-service_role בלבד, ולכל היותר הרשאת קריאה ל-authenticated.
הרשאה ל-anon נותנים רק לטבלה שמבקרים לא מחוברים באמת צריכים לקרוא, כמו רשימת מוצרים ציבורית, ורק אחרי שיש עליה RLS. הרשאה ל-anon על טבלה בלי RLS חושפת אותה לכל מי שפותח את האתר.
3. כתבו את התיקון כמיגרציה
אם הפרויקט מנוהל עם קבצי מיגרציה, שימו את ה-grant באותו קובץ שיוצר את הטבלה, ולא רק בעורך ה-SQL. כך הטבלה הבאה שתיווצר בסביבה אחרת, או בשחזור, תקבל את אותן הרשאות.
איך לא להיתקל בזה בטבלה הבאה?
כל טבלה חדשה מעכשיו צריכה שלושה דברים באותו מקום: יצירת הטבלה, הפעלת RLS עם מדיניות, והרשאה מפורשת לכל תפקיד שצריך אותה. כשכלי ה-AI מוסיף טבלה, בדקו שהוא הוסיף את שלושתם, ואחרי כל פיצ'ר חדש הריצו את השאילתה מלמעלה.
האפליקציה כבר באוויר ואתם לא בטוחים מה עוד השתנה? בדיקה לפני השקה עוברת על ההרשאות, ה-RLS, המפתחות והתשלומים ומסתיימת בדוח בעברית עם תיקונים לפי סדר עדיפות. אפשר גם לשלוח לנו הודעה בוואטסאפ עם השגיאה שקיבלתם.
