# בונים ב-No-Code? אל תפקירו את המידע שלכם: המדריך המלא לאבטחת אפליקציות ### למה המהירות של פיתוח ללא קוד עלולה להפוך למלכודת דבש של פרצות אבטחה, ואיך בונים חומת הגנה אמיתית לנתונים שלכם אחד היתרונות הכי גדולים ב-No-Code הוא המהירות. אנחנו יכולים להקים אפליקציה מורכבת תוך ימים במקום חודשים. אבל המהירות הזו מגיעה עם מחיר: לעיתים קרובות מדי, נושאי אבטחת המידע נדחקים לסוף הרשימה, או גרוע מכך – מסתמכים על הנחת היסוד המוטעית שהפלטפורמה (כמו Bubble, Supabase או Airtable) כבר "דואגת להכל". בפועל, בעוד שהפלטפורמות מספקות את התשתית המאובטחת, האחריות על **לוגיקת ההרשאות** היא עליכם. אם משתמש יכול לשנות פרמטר ב-URL ולראות הזמנות של לקוח אחר, זו לא תקלה בפלטפורמה – זו תקלה במימוש שלכם. בואו נצלול לכלים שיהפכו את האפליקציה שלכם ממסננת למבצר. ## RLS: שומר הסף שלכם ברמת השורה אחד המושגים החשובים ביותר בעולם ה-Backend המודרני (ובמיוחד בעבודה עם כלים כמו [Supabase](https://supabase.com/docs/guides/auth/row-level-security)) הוא **RLS - Row Level Security**. דמיינו מסד נתונים כבניין משרדים גדול. בקרת גישה רגילה בודקת רק אם יש לכם מפתח לבניין. RLS, לעומת זאת, בודק בפתח של כל משרד ומשרד אם השם שלכם מופיע על הדלת. ברמה הטכנית, RLS מוסיף סוג של "WHERE clause" אוטומטי לכל שאילתה. גם אם האקר ינסה להריץ שאילתה שתשלוף את כל המשתמשים, מסד הנתונים עצמו יחסום את הבקשה ויחזיר רק את השורות ששייכות לאותו משתמש. **הטיפ שלי:** לעולם אל תשאירו טבלאות עם גישה ציבורית ללא RLS מופעל. זהו קו ההגנה האחרון והחזק ביותר שלכם. ## Privacy Rules: כי מה שלא מוצג, עדיין קיים בפלטפורמות כמו [Bubble.io](https://manual.bubble.io/help-guides/data/the-database/protecting-data-with-privacy-rules), טעות נפוצה היא להסתמך על "הסתרה" (Hiding) של אלמנטים בממשק. אם הגדרתם ששדה ה-Social Security Number לא יופיע על המסך, זה לא אומר שהוא לא נשלח לדפדפן. כאן נכנסים ה-**Privacy Rules**. אלו כללים שרצים על השרת וקובעים איזה מידע בכלל יורד למכשיר של המשתמש. * **Find in searches:** האם המשתמש יכול בכלל למצוא את השורה הזו? * **View all fields:** האם הוא יכול לראות את כל השדות, או רק את השם והתמונה? זכרו: אם המידע הגיע לדפדפן (גם אם הוא לא מוצג ב-UI), משתמש מתוחכם יכול לראות אותו דרך ה-Network Tab בכלי המפתחים. אבטחה אמיתית קורית בשרת, לא במסך. ## בקרת גישה (RBAC) והצפנה ניהול הרשאות מבוסס תפקידים (**Role-Based Access Control**) הוא הסטנדרט בתעשייה. במקום להגדיר הרשאות לכל משתמש בנפרד, צרו תפקידים (Admin, Editor, Viewer). זה מונע טעויות אנוש ומוודא שכל משתמש מקבל את המינימום הנדרש לו לביצוע עבודתו (Principle of Least Privilege). בנוגע להצפנה, רוב הפלטפורמות המודרניות מצפינות נתונים בנסיעה (In Transit) באמצעות SSL/TLS. אבל מה לגבי נתונים רגישים במיוחד? 1. **הצפנה במנוחה (At Rest):** ודאו שהספק שלכם תומך בכך (רובם הגדול כן). 2. **ניהול מפתחות API:** לעולם אל תשתלו מפתחות API של שירותים חיצוניים (כמו OpenAI או Stripe) בתוך קוד ה-Frontend או בטבלאות נגישות. השתמשו ב-Environment Variables או ב-Backend Workflows מאובטחים. ## סיכום ומסקנות אבטחת מידע ב-No-Code היא לא "תוספת" שמוסיפים רגע לפני ההשקה – היא צריכה להיות חלק מתהליך הבנייה מהיום הראשון. **צ'ק ליסט מהיר עבורכם:** * האם הפעלתם RLS על כל הטבלאות במסד הנתונים? * האם הגדרתם Privacy Rules שמונעים ממידע רגיש לרדת לדפדפן שלא לצורך? * האם הפרדתם בין הרשאות ניהול להרשאות משתמש קצה? * האם כל מפתחות ה-API שלכם מאוחסנים בצורה מאובטחת בשרת? למי שרוצה להעמיק עוד יותר, אני ממליץ לעבור על פרויקט [OWASP Low-Code/No-Code Top 10](https://owasp.org/www-project-low-code-no-code-top-10/) שממפה את סיכוני האבטחה הנפוצים ביותר בתחום שלנו. בנייה ב-No-Code נותנת לנו כוח עצום. האחריות שלנו היא לוודא שהכוח הזה לא הופך לפרצת אבטחה שתפגע בלקוחות שלנו.