מדיניות RLS ב-SupabaseSupabase RLS Policies
הגדרה מהירה
מה זה Supabase RLS Policies? (TL;DR)
RLS policies ב-Supabase נכתבים ב-SQL וחלים על כל קריאה דרך API. הגנה על multi-tenant: בודקים auth.uid() מול org membership. תמיד WITH CHECK ב-INSERT/UPDATE.
ידוע גם בכתיבים: Supabase RLS · RLS Supabase · מדיניות RLS · policies Supabase · Row Level Security Supabase · supabase מדיניות אבטחה
עיקרי המונח (Key Takeaways)
- ▸RLS policies ב-Supabase = חוקי SQL שחלים אוטומטית על כל קריאה דרך ה-API.
- ▸ארבעה סוגי policies: SELECT, INSERT, UPDATE, DELETE - כל אחד דורש policy נפרד.
- ▸Multi-tenant pattern:
USING (auth.uid() IN (SELECT user_id FROM org_members WHERE org_id = ...)). - ▸תמיד הוסיפו
WITH CHECKל-INSERT/UPDATE - בלי זה אפשר להעלות הרשאה. - ▸הפעלה:
ALTER TABLE x ENABLE ROW LEVEL SECURITY;לפני יצירת ה-policy. - ▸Service role bypass: ה-service_role key עוקף RLS - לעולם לא בקליינט. בדיקה חיצונית תגלה אם הוא בכל זאת שם.
- ▸Testing: השתמשו ב-
SET LOCAL ROLE authenticated; SET LOCAL request.jwt.claims = ...;.
CREATE POLICY "users see own" ON orders FOR SELECT USING (auth.uid() = user_id);. Multi-tenant: FOR SELECT USING (auth.uid() IN (SELECT user_id FROM org_members WHERE org_id = orders.org_id));. ארבעה סוגי policies: SELECT (visibility), INSERT (מי יכול להוסיף - לרוב auth.uid()), UPDATE (מי יכול לערוך), DELETE (לרוב מוגבל ל-owner או admin). כלל זהב: תמיד הוסיפו WITH CHECK ל-INSERT/UPDATE כדי למנוע escalation - בלי זה user יכול לעדכן row של אחר. שגיאות נפוצות בפרויקטי Vibe Coding: שכחת ENABLE RLS על טבלה (שאר ה-DB פתוח), שימוש ב-service_role בצד הקליינט (עוקף הכל), missing WITH CHECK ב-INSERT. ראו RLS Security 2026 לסקירה רחבה.ציטוט
השתמשתם בדף הזה? תנו קרדיט.
עתונאים, חוקרים וצוותי AI - בחרו פורמט להעתקה. ה-citation האקדמי שלנו בקליק.
מונחים קשורים
אבטחת שורות (RLS)
שכבת אבטחה קריטית שמוודאת שה-AI לא מדליף מידע רגיש בין לקוחות. חובה לכל SaaS ב-2026.
אודיט אבטחה ל-Base44
בדיקה מקיפה של חוקי Row Level Security בפרויקט Base44 כדי למנוע דלף מידע בין משתמשים.
חוב טכנולוגי (Tech Debt)
העלות העתידית שנוצרת מפתרון מהיר, המייצר "כדורי בוץ" בקוד (Big Ball of Mud) ומונע הוספת פיצ'רים.
וייב קודינג
שיטת פיתוח שבה מתארים לסוכן AI בשפה טבעית מה המוצר צריך לעשות, והוא כותב את הקוד. המפתח עובר מכתיבה לביקורת. בעברית: וייב קודינג, ולעיתים קידוד לפי תחושה.
Cursor
Cursor הוא סביבת פיתוח (IDE) מבוססת AI שהפכה ב-2026 לסטנדרט בקרב מפתחי Vibe Coding בישראל ובעולם. מבוסס על fork של VS Code עם אינטגרציית AI עמוקה.
Claude Code (קלוד קוד)
Claude Code הוא ה-CLI של Anthropic לפיתוח אוטונומי עם AI. סטנדרט 2026 לעבודות planning + refactoring + MCP integrations.
שאלות נפוצות על מדיניות RLS ב-Supabase
מה ההבדל בין USING ל-WITH CHECK ב-policy?+
USING בודק אילו rows הקריאה רואה (SELECT, DELETE). WITH CHECK בודק אילו rows נשמרים (INSERT, UPDATE). חובה לציין WITH CHECK ב-UPDATE - אחרת user יכול לקרוא row לגיטימי ולעדכן אותו לערכים שאסור לו. דוגמה: FOR UPDATE USING (auth.uid() = user_id) WITH CHECK (auth.uid() = user_id).
איך עושים multi-tenant RLS ב-Supabase?+
הדפוס הסטנדרטי: טבלת org_members(org_id, user_id, role). Policy: FOR SELECT USING (org_id IN (SELECT org_id FROM org_members WHERE user_id = auth.uid())). ליעילות, השתמשו ב-helper function: CREATE FUNCTION auth.user_orgs() RETURNS uuid[] STABLE.... זה מאפשר caching של ה-query לכל request.
איך לבדוק RLS בלי לפרוס לפרודקשן?+
דרך 1: SQL Editor של Supabase עם SET LOCAL ROLE authenticated; SET LOCAL request.jwt.claims = '{"sub": "user-uuid"}'; ואז מריצים queries. דרך 2: supabase test db CLI עם pgTAP. דרך 3 (מומלצת): integration tests עם @supabase/supabase-js שמתחבר כ-user אמיתי. ראו Audit Framework לתהליך מלא.
האם service_role בטוח ב-server-side functions?+
כן - אבל רק ב-server (Edge Functions, API routes, background jobs). לעולם לא בקליינט. בקוד צד-שרת השתמשו ב-SUPABASE_SERVICE_ROLE_KEY רק כש-(1) ביצעתם authorization בעצמכם, (2) הפעולה דורשת bypass של RLS (למשל webhook handler), או (3) admin tasks. כלל זהב: אם user יכול להפעיל את ה-endpoint, חזרו ל-anon key + RLS.
אילו דפוסי RLS נפוצים ב-Vibe Coding שנשברים?+
הנפוצים שאנחנו רואים: (1) שכחת ENABLE ROW LEVEL SECURITY על טבלה (RLS off - כולם רואים הכל), (2) policy רק על SELECT - INSERT/UPDATE/DELETE פתוחים לחלוטין, (3) missing WITH CHECK ב-UPDATE - escalation possible, (4) recursive policy על join table (infinite loop, timeout), (5) שימוש ב-service_role בקליינט (אסון אבטחתי מוחלט). ב-VibeScale Rescue הזה הולך first.
מדברים בוואטסאפ, לא בטפסים
תארו בשתי שורות מה שבור או מה החלום. ההודעה נפתחת אצלכם מוכנה. אתם רק לוחצים שלח.
מעדיפים להתקשר? 054-211-8143