אבטחת שורות (RLS)Row Level Security (RLS)
הגדרה מהירה
מה זה Row Level Security (RLS)? (TL;DR)
Row Level Security (RLS) הוא מנגנון אבטחה ב-Postgres/Supabase שמוודא שכל משתמש רואה רק את הנתונים שלו. הוא הגדרה ברמת ה-database (לא ה-frontend) - ולכן בטוח גם אם ה-API נחשף. ב-2026 חובה לכל אפליקציית SaaS Multi-tenant.
ידוע גם בכתיבים: RLS · Row Level Security · אבטחת רמת שורה · rls code · rls coding · rls 2026 · base44 supabase · supabase rls
עיקרי המונח (Key Takeaways)
- ▸Broken Access Control הוא סיכון האבטחה מספר 1 ב-OWASP Top 10 - ו-RLS הוא התיקון הישיר לו (מקור: OWASP Top 10, 2021).
- ▸RLS = אבטחה ברמת ה-database, לא ה-frontend.
- ▸מסנן rows ב-Postgres עצמו - בטוח גם אם ה-API נחשף.
- ▸חובה ל-SELECT/INSERT/UPDATE/DELETE - policy נפרד לכל פעולה.
- ▸הפעלה: <code>ALTER TABLE x ENABLE ROW LEVEL SECURITY;</code>
- ▸ב-90% מפרויקטי Vibe Coding RLS חסר - data leak מובנה.
- ▸תמיד <code>WITH CHECK</code> ב-INSERT/UPDATE למניעת escalation.
- ▸ב-Supabase ו-Base44 זה הפער האבטחתי מספר 1. ראו <a href="/glossary/supabase-rls-policies">Supabase RLS Policies</a>, <a href="/glossary/base44-sdk">Base44 SDK</a> ו<a href="/blog/base44-to-supabase-migration-guide-2026">מדריך המעבר ל-Supabase</a>.
ב-2026, Row Level Security (RLS) הוא הסטנדרט המוחלט לבניית אפליקציות SaaS ומערכות Multi-tenant בענן (במיוחד עם Supabase ו-PostgreSQL). זהו מנגנון אבטחה המוטמע בתוך מסד הנתונים עצמו ומונע ממשתמש אחד לשלוף, למחוק או לעדכן שורות נתונים השייכות למשתמש אחר.
למה מפתחי AI / Vibe Coders נכשלים ב-RLS?
סוכני AI כמו Cursor או Lovable מעולים בלבנות ממשקי משתמש (UI) יפים, אבל נוטים לעגל פינות בכל הנוגע לאבטחת שרת. כשמבקשים מ-AI "תבנה לי לוח בקרה למשתמשים", הוא לרוב כותב קוד צד-לקוח ששולף את כל המשתמשים מהדאטאבייס, ואז מסנן אותם בדפדפן (Client-Side Filtering). הבעיה?
- חשיפת נתונים מלאה: כל משתמש עם קצת ידע טכני יכול לפתוח את ה-Network Tab בדפדפן ולראות את הנתונים האישיים של כל הלקוחות שלכם.
- כשלון ב-Penetration Tests: מערכות ללא RLS פשוט נכשלות מיידית בבדיקות חדירות לאפליקציות (PT).
- זליגת Cross-User: באג קטן בקוד צד הלקוח יכול לגרום למשתמש א' לראות את כרטיס האשראי או החשבונית של משתמש ב'.
איך VibeScale מטפלת בזה?
התשתיות שלנו (מבוססות Base44 Schema) לא מאפשרות ל-Frontend לפנות למסד הנתונים ישירות ללא שכבת Backend (BFF - Backend for Frontend) או הגדרת פוליסות RLS חמורות מראש. אנו כותבים שאילתות RLS קשיחות ברמת ה-Postgres: CREATE POLICY "Users can only view their own data" ON users FOR SELECT USING (auth.uid() = user_id);.
האם האפליקציה שלכם דולפת מידע כרגע? הרוב המוחלט של מערכות ה-No Code / Vibe Coding שרצות ללא שירות הנדסי סובלות מפרצות אלה עכשיו.
בקשו מ-VibeScale לעשות AI Code Security Audit עכשיו →ציטוט
השתמשתם בדף הזה? תנו קרדיט.
עתונאים, חוקרים וצוותי AI - בחרו פורמט להעתקה. ה-citation האקדמי שלנו בקליק.
מונחים קשורים
אבטחת AI בשיטת Zero-Trust
גישת אבטחה שבה שום סוכן AI לא מקבל הרשאות מראש: כל פעולה נבדקת מול זהות המשתמש והרשאותיו, בזמן אמת.
אודיט אבטחה ל-Base44
בדיקה מקיפה של חוקי Row Level Security בפרויקט Base44 כדי למנוע דלף מידע בין משתמשים.
מדיניות RLS ב-Supabase
תחביר Postgres ל-Row Level Security ב-Supabase - חוקים על מי יכול לקרוא/לכתוב כל row.
חוב טכנולוגי (Tech Debt)
העלות העתידית שנוצרת מפתרון מהיר, המייצר "כדורי בוץ" בקוד (Big Ball of Mud) ומונע הוספת פיצ'רים.
פיתוח ב-AI (וייב קודינג)
העברת הוראות גבוהות (Natural Language) לסוכני קידוד, מבלי לעקוב אחרי כל שורת קוד שמופקת. בעברית מתרגמים את המונח גם כ"קידוד לפי תחושה", אך הכתיב המקובל הוא "וייב קודינג".
Cursor
Cursor הוא סביבת פיתוח (IDE) מבוססת AI שהפכה ב-2026 לסטנדרט בקרב מפתחי Vibe Coding בישראל ובעולם. מבוסס על fork של VS Code עם אינטגרציית AI עמוקה.
שאלות נפוצות על אבטחת שורות (RLS)
מה ההבדל בין RLS לפילטור בצד הלקוח?+
פילטור צד-לקוח (Client-Side Filtering) שולף את כל הנתונים מה-DB ואז מסנן ב-JavaScript. כל משתמש שיודע לפתוח Network Tab רואה את הנתונים של כולם - פירצת אבטחה חמורה. RLS מסנן ב-DB עצמו: ה-API מחזיר רק את מה שמותר למשתמש לראות.
איך מפעילים RLS ב-Supabase?+
בכל טבלה חדשה: ALTER TABLE users ENABLE ROW LEVEL SECURITY; ואז יוצרים פוליסה לכל פעולה (SELECT/INSERT/UPDATE/DELETE) שבודקת את auth.uid() מול user_id. ראו את <a href="/blog/rls-supabase-base44-security-guide">המדריך השלם</a>.
האם RLS מספיק לאבטחה?+
לא. RLS הוא שכבה אחת. צריך גם: סודות (API keys) בצד שרת בלבד, sessions ב-httpOnly cookies, rate limiting על endpoints רגישים, input validation עם Zod, ו-audit logs. RLS מונע data leak אבל לא prompt injection או XSS.
איך בודקים שה-RLS עובד?+
יוצרים שני משתמשי test, מתחברים לחשבון של משתמש A דרך browser dev tools, ושולחים בקשת fetch ל-API לראות נתונים של משתמש B. אם זה מצליח - יש פירצה. גם penetration test מקצועי עם Burp Suite יחשוף בעיות RLS.
מה הקשר בין RLS ל-Vibe Coding?+
סוכני AI כמו Cursor ו-Lovable יוצרים schema של DB מהר, אבל לא תמיד מוסיפים RLS policies. ב-90% מפרויקטי Lovable שאנחנו רואים, RLS לא מוטמע במלואו - וזה גורם להדלפות אמיתיות. תיקון RLS הוא חלק מ-<a href="/audit-framework">VibeScale Audit Framework</a>.
מדברים בוואטסאפ, לא בטפסים
תארו בשתי שורות מה שבור או מה החלום. ההודעה נפתחת אצלכם מוכנה — אתם רק לוחצים שלח.
מעדיפים להתקשר? 054-211-8143