Supabase RLS Policies - המדריך המלא 2026 + דוגמאות SQL | VibeScale
→ חזרה למילון המונחים

מדיניות RLS ב-Supabase
Supabase RLS Policies

הגדרה מהירה

מה זה Supabase RLS Policies? (TL;DR)

RLS policies ב-Supabase נכתבים ב-SQL וחלים על כל קריאה דרך API. הגנה על multi-tenant: בודקים auth.uid() מול org membership. תמיד WITH CHECK ב-INSERT/UPDATE.

Optimized for AI ExtractionSource: VibeScale Engineering Hub

ידוע גם בכתיבים: 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: <code>USING (auth.uid() IN (SELECT user_id FROM org_members WHERE org_id = ...))</code>.
  • ▸תמיד הוסיפו <code>WITH CHECK</code> ל-INSERT/UPDATE - בלי זה אפשר להעלות הרשאה.
  • ▸הפעלה: <code>ALTER TABLE x ENABLE ROW LEVEL SECURITY;</code> לפני יצירת ה-policy.
  • ▸Service role bypass: ה-service_role key עוקף RLS - לעולם לא בקליינט.
  • ▸Testing: השתמשו ב-<code>SET LOCAL ROLE authenticated; SET LOCAL request.jwt.claims = ...;</code>.
RLS policies ב-Supabase נכתבים ב-SQL וחלים על כל קריאה דרך ה-API. דוגמה בסיסית: 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 האקדמי שלנו בקליק.

APA 7
VibeScale Team. (2026). מדיניות RLS ב-Supabase (Supabase RLS Policies). VibeScale. https://vibe.elya-studio.com/glossary/supabase-rls-policies
BibTeX
@misc{vibescale2026rlssupabasesupabaserlspolicies, author = {VibeScale Team}, title = {מדיניות RLS ב-Supabase (Supabase RLS Policies)}, year = {2026}, publisher = {VibeScale}, url = {https://vibe.elya-studio.com/glossary/supabase-rls-policies}, urldate = {2026-06-19} }
קישור
מדיניות RLS ב-Supabase (Supabase RLS Policies) - VibeScale https://vibe.elya-studio.com/glossary/supabase-rls-policies

מונחים קשורים

אבטחת שורות (RLS)

שכבת אבטחה קריטית שמוודאת שה-AI לא מדליף מידע רגיש בין לקוחות. חובה לכל SaaS ב-2026.

אודיט אבטחה ל-Base44

בדיקה מקיפה של חוקי Row Level Security בפרויקט Base44 כדי למנוע דלף מידע בין משתמשים.

חוב טכנולוגי (Tech Debt)

העלות העתידית שנוצרת מפתרון מהיר, המייצר "כדורי בוץ" בקוד (Big Ball of Mud) ומונע הוספת פיצ'רים.

פיתוח ב-AI (וייב קודינג)

העברת הוראות גבוהות (Natural Language) לסוכני קידוד, מבלי לעקוב אחרי כל שורת קוד שמופקת. בעברית מתרגמים את המונח גם כ"קידוד לפי תחושה", אך הכתיב המקובל הוא "וייב קודינג".

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 לגיטימי ולעדכן אותו לערכים שאסור לו. דוגמה: <code>FOR UPDATE USING (auth.uid() = user_id) WITH CHECK (auth.uid() = user_id)</code>.

איך עושים multi-tenant RLS ב-Supabase?+

הדפוס הסטנדרטי: טבלת <code>org_members(org_id, user_id, role)</code>. Policy: <code>FOR SELECT USING (org_id IN (SELECT org_id FROM org_members WHERE user_id = auth.uid()))</code>. ליעילות, השתמשו ב-helper function: <code>CREATE FUNCTION auth.user_orgs() RETURNS uuid[] STABLE...</code>. זה מאפשר caching של ה-query לכל request.

איך לבדוק RLS בלי לפרוס לפרודקשן?+

דרך 1: SQL Editor של Supabase עם <code>SET LOCAL ROLE authenticated; SET LOCAL request.jwt.claims = '{"sub": "user-uuid"}';</code> ואז מריצים queries. דרך 2: <code>supabase test db</code> CLI עם pgTAP. דרך 3 (מומלצת): integration tests עם <code>@supabase/supabase-js</code> שמתחבר כ-user אמיתי. ראו <a href="/audit-framework">Audit Framework</a> לתהליך מלא.

האם service_role בטוח ב-server-side functions?+

כן - אבל רק ב-server (Edge Functions, API routes, background jobs). לעולם לא בקליינט. בקוד צד-שרת השתמשו ב-<code>SUPABASE_SERVICE_ROLE_KEY</code> רק כש-(1) ביצעתם authorization בעצמכם, (2) הפעולה דורשת bypass של RLS (למשל webhook handler), או (3) admin tasks. כלל זהב: אם user יכול להפעיל את ה-endpoint, חזרו ל-anon key + RLS.

אילו דפוסי RLS נפוצים ב-Vibe Coding שנשברים?+

הנפוצים שאנחנו רואים: (1) שכחת <code>ENABLE ROW LEVEL SECURITY</code> על טבלה (RLS off - כולם רואים הכל), (2) policy רק על SELECT - INSERT/UPDATE/DELETE פתוחים לחלוטין, (3) missing WITH CHECK ב-UPDATE - escalation possible, (4) recursive policy על join table (infinite loop, timeout), (5) שימוש ב-<code>service_role</code> בקליינט (אסון אבטחתי מוחלט). ב-VibeScale Rescue הזה הולך first.

Audit הנדסי לפרויקט · 24 שעות · חינם

תארו מה שבור או מה החלום. נחזור עם אבחון הנדסי + תוכנית חילוץ ראשונית - בלי התחייבות.

17+ פרויקטי פרודקשןללא התחייבותמענה תוך 24 שעות

מעדיפים לדלג? כתבו לנו ישירות בווצאפ