חובה
כל מה שנמצא בקוד של הדפדפן, כל אחד רואה. מפתחות סודיים (OpenAI, Stripe secret, Resend, service_role של Supabase) רק בצד שרת או ב-Secrets.
בדיקה של 30 שניותבאתר החי, F12 ← Sources ← Ctrl+Shift+F, חפשו `sk-`, `secret`, `service_role`, `key`.
$ cat /guidelines
הנחיות אבטחה לפני ובמהלך הפיתוח
143 בדיקות מעשיות לפיתוח מאובטח לפי שפה וסביבה, לצד WordPress ו-Vibe Coding.
אבטחת אתר שנבנה בעזרת AI מתחילה בסודות שמורים בשרת ובגישה מוגבלת למידע. עברו על עשר הבדיקות החשובות, ואז על המסלול המתאים לסביבה שלכם; סימון הצ'קליסט אינו תחליף לבדיקה בפועל.
עודכן תוכן העמוד: · מערכת VibeSec · מדיניות המקורות
10 הדברים שאסור לדלג עליהם
הושלמו 0 מתוך 10
לפני הפיתוח
חובה
להחליט מראש: מה ציבורי, מה רק למשתמש עצמו, מה רק למנהל. תפקיד מנהל נשמר בטבלה נפרדת, לא בפרופיל ולא בדפדפן.
בדיקה של 30 שניותכתבו בשלוש שורות את התפקידים ומה כל אחד רואה.
במהלך הפיתוח
חובה
הפרצה הנפוצה ביותר באפליקציות Lovable: טבלה שכל אחד יכול לקרוא.
בדיקה של 30 שניותSupabase ← Table Editor: ליד כל טבלה RLS enabled. ואז Advisors ← Security Advisor, אפס אזהרות אדומות.
חובה
אם משנים מספר ב-URL או בבקשה (id=5 ← id=6) ורואים נתונים של מישהו אחר, זו פרצה.
בדיקה של 30 שניותהתחברו עם שני משתמשים ונסו לפתוח רשומה של המשתמש השני.
חובה
Bucket ציבורי = כל קובץ נגיש לכל מי שיש לו קישור. מסמכים, חשבוניות ותעודות רק ב-bucket פרטי עם קישורים חתומים.
בדיקה של 30 שניותSupabase ← Storage: איזה bucket מסומן Public, והאם זה מכוון.
חובה
Edge Function בלי בדיקת התחברות = כל אחד יכול להפעיל אותה, כולל קריאות בתשלום.
בדיקה של 30 שניותבקשו מה-AI רשימה של כל ה-Edge Functions ומי מורשה להפעיל כל אחת.
מומלץ
מודלים ממציאים שמות חבילות, ותוקפים רושמים בדיוק את השמות האלה.
בדיקה של 30 שניותלכל חבילה חדשה: קיימת ב-npm, הורדות שבועיות גבוהות, עדכון בשנה האחרונה. `npm audit` בלי high/critical.
לפני עלייה לאוויר
חובה
טופס בלי הגבלה + API בתשלום = חשבונית של אלפי שקלים בלילה אחד.
בדיקה של 30 שניותב-OpenAI / Anthropic / Resend / Stripe הוגדרה תקרת הוצאה חודשית והתראה.
חובה
לפתוח את האתר בחלון אנונימי, בלי להתחבר, ולנסות להגיע לכל עמוד וכל נתון.
בדיקה של 30 שניותחלון גלישה בסתר ← עמודי ניהול, דשבורד, API. ואז הסורק המובנה של Lovable (Security scan).
מומלץ
גיבוי: מסד הנתונים מגובה (ב-Supabase: Backups / PITR) וניסיתם שחזור. דליפת מפתח: מבטלים אותו אצל הספק, מנפיקים חדש, בודקים לוגים — מחיקה מהקוד לא מספיקה, הוא נשאר בהיסטוריה. אימייל: אישור אימייל פעיל, ו-Redirect URLs מוגבלים לדומיין שלכם.
בדיקה של 30 שניותודאו שניסיתם שחזור, שיש דרך לבטל כל מפתח, שאישור אימייל פעיל ושכתובות ההפניה מוגבלות לדומיין שלכם.
פיתוח עם Lovable, Cursor, Claude Code וסוכני AI אחרים. הקוד נכתב מהר — והפרצות נכנסות מהר באותה מידה.
$ הושלמו 0 מתוך 34 בדיקות (0%)
1
לפני הפיתוח
מה להגדיר לפני שכותבים שורת פרומפט אחת
מה יקרה אם מישהו זר יראה את המידע
לפני שמבקשים מהסוכן לבנות מסך, כתבו במשפט אחד מי המשתמשים, איזה מידע רגיש נשמר, ומה קורה אם מישהו זר יראה אותו. השתמשו ברשימה הזו כדי לבדוק כל דבר שה-AI בונה, והיא מה שמונע את התרחיש הנפוץ שבו טבלה עם פרטי לקוחות נולדת ציבורית.
מונחים:
החליטו מי יכול לראות ולשנות כל דבר
סוכני AI נוטים לבנות אפליקציה שבה כל משתמש מחובר רואה הכול. הגדירו מראש את התפקידים (משתמש, מנהל, אורח), מה כל אחד רשאי לעשות, ואיפה נשמר התפקיד — תמיד בטבלת תפקידים נפרדת ולעולם לא בטבלת הפרופיל ולא בצד הלקוח.
מונחים:
תכננו מראש איפה יישמרו הסודות
מפתחות סודיים וסיסמאות לא נשמרים בקוד שמגיע לדפדפן או בהגדרות שמתחילות ב-VITE_. כל מבקר יכול לקרוא אותם. מפתחות ציבוריים מיועדים לדפדפן, אך אינם מחליפים בדיקת הרשאות. בקשו מה-AI לשמור את הסודות בשרת בלבד.
מונחים:
2
במהלך הפיתוח
מה לבדוק אחרי כל פרומפט שמייצר קוד
כל טבלה חדשה — מי רשאי לגשת לכל רשומה
טבלה חדשה עלולה לחשוף את פרטי הלקוחות לכולם. RLS הוא מנגנון שמגביל מי יכול לראות ולשנות כל רשומה. אחרי הוספת טבלה או שינוי שלה, בקשו מה-AI להציג את כללי הגישה ובדקו אותם עם שני משתמשים שונים.
מונחים:
אל תסמכו על קוד שלא קראתם
קוד שה-AI כתב יכול להיראות תקין ועדיין לחשוף מידע. בקשו הסבר לכל פעולה בשרת: מי יכול להפעיל אותה, איזה מידע היא מקבלת ומה היא מחזירה. ודאו ששינוי מספר הרשומה בקישור לא פותח מידע של לקוח אחר.
מונחים:
לא נותנים ל-AI לבצע כל הוראה שהוא קורא
טקסט מאתר או ממסמך יכול לכלול הוראות שמנסות לגרום ל-AI לחשוף מידע או למחוק אותו. הגדירו מה מותר ל-AI לעשות, ודרשו אישור לפני מחיקה, תשלום או פעולה שלא ניתן לבטל.
מונחים:
בדקו כל חבילה שה-AI הציע
מודלים ממציאים שמות חבילות שלא קיימות, ותוקפים רושמים בדיוק את השמות האלה בסביבות הפתוחות. לפני התקנה, ודאו שהחבילה אמיתית, פעילה ובעלת שימוש רחב.
מונחים:
3
לפני עלייה לאוויר
הבדיקות שאסור לדלג עליהן לפני פרסום
סריקה אחרונה לפני פרסום
לפני שהאתר נגיש לציבור, הריצו סריקת אבטחה, ודאו שאין סודות בקוד, ובדקו את האפליקציה בדפדפן במצב אורח — בלי התחברות — כדי לראות מה באמת חשוף.
מונחים:
קריאה נוספת
בדיקת חדירות (PT): מתי נכון לעשות, ולמה
אמ;לק: בדיקת חדירות (Penetration Test, PT) היא ניסיון פריצה מבוקר שעושה אדם מקצועי לאתר או לאפליקציה שלכם, כדי למצוא חולשות לפני שתוקף אמיתי ימצא אותן. היא שווה את הכסף כשיש לכם משתמשים אמיתיים, מידע רגיש או כסף שעובר במערכת, ואחרי שכבר עשיתם את הבדיקות הבסיסיות בעצמכם. לפני זה, רוב הממצאים יהיו דברים שסורק חינמי היה מוצא.
גיא אקרמן · 4 דקות קריאה
ליווי של איש אבטחת מידע תוך כדי פיתוח: כן, לא, ומתי
אמ;לק: ליווי אבטחה בזמן הפיתוח שווה את הכסף כשהמערכת מחזיקה מידע רגיש או כסף, כשאין בצוות אף אחד שמבין באבטחה, או כשבונים מהר עם AI ומשנים הרבה. לא חייבים ליווי צמוד: לרוב מספיקות כמה נקודות מפגש קבועות. לפרויקט קטן בלי מידע רגיש בדרך כלל מספיק צ'קליסט טוב, וליווי מלא יהיה בזבוז.
גיא אקרמן · 3 דקות קריאה
אבטחת סקילים וסוכני AI
אבטחת סקילים — מקורות מהימנים וכלי בדיקהשאלות נפוצות
איך בודקים אם האתר שבניתי ב-Lovable מאובטח?
מתחילים בבדיקת סודות, הרשאות לכל רשומה ואחסון קבצים. בודקים כאורח ועם שני משתמשים שונים, מריצים סריקת אבטחה ומטפלים בממצאים. סריקה לבדה אינה הוכחה שהאתר בטוח.
מה זה RLS ב-Supabase?
RLS מגביל גישה לשורות במסד הנתונים לפי כללי הרשאה. יש להפעיל אותו ולכתוב מדיניות מפורשת לקריאה ולשינוי, ואז לבדוק כמשתמש שאינו הבעלים. מפתח שרת בעל הרשאות רחבות יכול לעקוף RLS.
האם מפתח API בקוד של האתר מסוכן?
מפתח סודי בקוד שמגיע לדפדפן נגיש לכל מבקר. שומרים אותו בשרת בלבד; אם דלף, מבטלים ומחליפים אצל הספק. מפתח ציבורי שמיועד לדפדפן אינו סוד, אך אינו מחליף הרשאות והגבלות שימוש.
איך מגינים על אתר WordPress?
מעדכנים ליבה, תוספים ותבניות ממקורות רשמיים, מסירים הרחבות מיותרות ומפעילים אימות דו-שלבי למנהלים. מוסיפים הגבלת ניסיונות כניסה, הרשאות מצומצמות וגיבוי שנבדק בשחזור.
האם כלי AI יכול להחליף בדיקת אבטחה?
לא. AI מסייע לכתוב ולסקור קוד אך עלול להחמיץ הרשאות, להמציא חבילות או לפרש תוכן זדוני כהוראות. משלבים סקירה אנושית, בדיקות הרשאות וסורקים המתאימים לסביבה.
מה עושים אם מפתח או מידע דלפו?
מבטלים מפתחות חשופים, מצמצמים גישה, שומרים ראיות ובודקים יומני פעילות. מתקנים את נתיב החשיפה ובודקים גיבוי ושחזור. מחיקת המפתח מהקוד בלבד אינה מבטלת אותו או מוחקת את ההיסטוריה.
