איך בונים אפליקציות מאובטחות
בעידן הוייב קודינג

בניית אפליקציות עם AI היא מהירה ומרגשת. אבל יש משהו שחשוב לא לשכוח בכל ההתלהבות: אבטחה.

כשבונים מערכת שמחזיקה נתונים של לקוחות — שמות, מיילים, מידע אישי — יש אחריות אמיתית. טעות אבטחה יכולה לחשוף מידע, לפגוע באמון, ואפילו ליצור בעיות משפטיות.

החדשות הטובות? אבטחה בסיסית היא לא מסובכת. במאמר הזה נעבור על העקרונות החשובים ביותר, עם דגש על וייב קודינג.

הכלל הראשון: Secrets לא בקוד!

זו הטעות הנפוצה ביותר, ואחת הקריטיות ביותר. Secrets כוללים:

• מפתחות API (OpenAI, Supabase, Stripe וכו')
• סיסמאות למסדי נתונים
• טוקנים לשירותים חיצוניים
• מפתחות הצפנה

למה זה בעיה? כשמעלים קוד ל-GitHub (גם ל-repository פרטי), כל מי שיש לו גישה יכול לראות את ה-secrets. וב-repository ציבורי? כל העולם יכול.

אתרים סורקים GitHub כל הזמן בחיפוש אחר מפתחות API חשופים. ברגע שמפתח נחשף, הוא יכול לשמש תוך דקות.

הפתרון: משתני סביבה (Environment Variables)

במקום לכתוב:

const API_KEY = "sk-abc123xyz..." // לא לעשות!

כותבים:

const API_KEY = process.env.OPENAI_API_KEY

והמפתח עצמו נשמר בקובץ .env שלא עולה ל-GitHub (צריך להוסיף אותו ל-.gitignore).

Supabase RLS: ההגנה על מסד הנתונים

Supabase הוא כלי מצוין לבניית מערכות, אבל בלי RLS, כל מי שיש לו את ה-URL יכול לקרוא את כל הנתונים.

מה זה RLS?

Row Level Security (אבטחה ברמת השורה) מאפשרת להגדיר בדיוק מי יכול לעשות מה:

• משתמש יכול לראות רק את השורות שלו
• רק המשתמש שיצר רשומה יכול למחוק אותה
• אדמין יכול לראות הכל
• משתמשים לא מחוברים לא יכולים לראות כלום

איך זה עובד בפועל?

ב-Supabase, אחרי שיוצרים טבלה, צריך:

1. להפעיל RLS — בהגדרות הטבלה
2. ליצור policies — כללים שמגדירים מי יכול לקרוא/לכתוב

דוגמה לpolicy שמאפשרת למשתמש לראות רק את השורות שלו:

auth.uid() = user_id

טעויות נפוצות עם RLS

• לשכוח להפעיל RLS — הטבלה פתוחה לכולם
• policy רחבה מדי — כל משתמש יכול לראות הכל
• לשכוח policy ל-INSERT/UPDATE — בדקו את כל הפעולות

אימות משתמשים (Authentication)

אימות משתמשים הוא הבסיס של כל מערכת מאובטחת. אל תמציאו את הגלגל מחדש — השתמשו בפתרונות מוכנים:

מה לא לעשות

• לשמור סיסמאות בטקסט גלוי — תמיד להשתמש ב-hash
• לבנות מערכת אימות מאפס — יש פתרונות מוכנים ומאובטחים
• להתעלם מ-2FA — אם אפשר, להציע אימות דו-שלבי

ולידציה: לא לסמוך על קלט המשתמש

כלל בסיסי באבטחה: כל קלט שמגיע מהמשתמש חשוד.

גם אם יש לך טופס עם שדה אימייל, מישהו יכול לשלוח לך משהו אחר לגמרי. תמיד לבדוק:

• סוג הנתון — מספר באמת מספר? מייל באמת מייל?
• אורך — לא לקבל טקסט של מיליון תווים
• תווים מסוכנים — הגנה מפני SQL Injection ו-XSS

כלים לולידציה

• Zod — ספריית ולידציה פופולרית ל-JavaScript/TypeScript
• Yup — חלופה נפוצה
• Supabase Edge Functions — ולידציה בצד השרת

סיכוני תלויות (Dependencies)

כשמשתמשים ב-npm packages, יש סיכון שחבילה מסוימת מכילה קוד זדוני או פרצות אבטחה.

מה לעשות

• להשתמש בחבילות פופולריות — יותר עיניים, יותר בטוח
• לעדכן תלויות — npm audit מזהה פרצות ידועות
• לבדוק לפני התקנה — כמה הורדות? תחזוקה פעילה?
• להשתמש ב-lock files — package-lock.json

לסקור קוד של AI

כאן מגיעה נקודה קריטית לוייב קודינג: AI יכול לכתוב קוד לא מאובטח.

AI לא "זדוני", אבל הוא יכול:

• לשכוח להוסיף ולידציה
• לחשוף secrets בטעות
• להשתמש בתבניות לא מאובטחות
• לדלג על בדיקות הרשאות

גיבויים

אבטחה היא לא רק הגנה מפני תוקפים — היא גם הגנה מפני טעויות וקריסות.

• Supabase — גיבויים אוטומטיים בתוכניות בתשלום
• Vercel — כל deployment נשמר כגרסה
• GitHub — היסטוריית commits היא גיבוי של הקוד

כלל אצבע: גיבוי שלא בדקתם — לא גיבוי. תבדקו שאתן יכולות לשחזר.

צ'קליסט אבטחה לפני העלאה לאוויר

שאלות נפוצות

מה זה secrets ולמה לא לשים אותם בקוד?

Secrets הם מידע רגיש כמו מפתחות API וסיסמאות. בקוד שעולה ל-GitHub, כל אחד יכול לראות אותם. משתמשים במשתני סביבה במקום.

מה זה Supabase RLS?

Row Level Security — מערכת הרשאות שמגדירה מי יכול לראות ולערוך כל שורה במסד הנתונים.

האם AI יכול לכתוב קוד לא מאובטח?

כן. לכן חשוב לסקור כל קוד, במיוחד בנושאי אבטחה.

מה חובה לבדוק לפני העלאה לאוויר?

שאין secrets בקוד, ש-RLS מופעל, שיש ולידציה, שההרשאות נכונות, ושיש גיבוי.