חובה
כל מה שנמצא בקוד של הדפדפן, כל אחד רואה. מפתחות סודיים (OpenAI, Stripe secret, Resend, service_role של Supabase) רק בצד שרת או ב-Secrets.
בדיקה של 30 שניותבאתר החי, F12 ← Sources ← Ctrl+Shift+F, חפשו `sk-`, `secret`, `service_role`, `key`.
$ cat /guidelines
הנחיות אבטחה לפני ובמהלך הפיתוח: Node.js / JS / TS
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 שניותודאו שניסיתם שחזור, שיש דרך לבטל כל מפתח, שאישור אימייל פעיל ושכתובות ההפניה מוגבלות לדומיין שלכם.
בדיקות ממוקדות לצד מסלול הפיתוח הכללי, לפני שחרור קוד שנוצר בעזרת AI.
$ הושלמו 0 מתוך 5 בדיקות (0%)
קריאה נוספת
בדיקת חדירות (PT): מתי נכון לעשות, ולמה
אמ;לק: בדיקת חדירות (Penetration Test, PT) היא ניסיון פריצה מבוקר שעושה אדם מקצועי לאתר או לאפליקציה שלכם, כדי למצוא חולשות לפני שתוקף אמיתי ימצא אותן. היא שווה את הכסף כשיש לכם משתמשים אמיתיים, מידע רגיש או כסף שעובר במערכת, ואחרי שכבר עשיתם את הבדיקות הבסיסיות בעצמכם. לפני זה, רוב הממצאים יהיו דברים שסורק חינמי היה מוצא.
גיא אקרמן · 4 דקות קריאה
ליווי של איש אבטחת מידע תוך כדי פיתוח: כן, לא, ומתי
אמ;לק: ליווי אבטחה בזמן הפיתוח שווה את הכסף כשהמערכת מחזיקה מידע רגיש או כסף, כשאין בצוות אף אחד שמבין באבטחה, או כשבונים מהר עם AI ומשנים הרבה. לא חייבים ליווי צמוד: לרוב מספיקות כמה נקודות מפגש קבועות. לפרויקט קטן בלי מידע רגיש בדרך כלל מספיק צ'קליסט טוב, וליווי מלא יהיה בזבוז.
גיא אקרמן · 3 דקות קריאה
אבטחת סקילים וסוכני AI
אבטחת סקילים — מקורות מהימנים וכלי בדיקהשאלות נפוצות
איך בודקים אם האתר שבניתי ב-Lovable מאובטח?
מתחילים בבדיקת סודות, הרשאות לכל רשומה ואחסון קבצים. בודקים כאורח ועם שני משתמשים שונים, מריצים סריקת אבטחה ומטפלים בממצאים. סריקה לבדה אינה הוכחה שהאתר בטוח.
מה זה RLS ב-Supabase?
RLS מגביל גישה לשורות במסד הנתונים לפי כללי הרשאה. יש להפעיל אותו ולכתוב מדיניות מפורשת לקריאה ולשינוי, ואז לבדוק כמשתמש שאינו הבעלים. מפתח שרת בעל הרשאות רחבות יכול לעקוף RLS.
האם מפתח API בקוד של האתר מסוכן?
מפתח סודי בקוד שמגיע לדפדפן נגיש לכל מבקר. שומרים אותו בשרת בלבד; אם דלף, מבטלים ומחליפים אצל הספק. מפתח ציבורי שמיועד לדפדפן אינו סוד, אך אינו מחליף הרשאות והגבלות שימוש.
איך מגינים על אתר WordPress?
מעדכנים ליבה, תוספים ותבניות ממקורות רשמיים, מסירים הרחבות מיותרות ומפעילים אימות דו-שלבי למנהלים. מוסיפים הגבלת ניסיונות כניסה, הרשאות מצומצמות וגיבוי שנבדק בשחזור.
האם כלי AI יכול להחליף בדיקת אבטחה?
לא. AI מסייע לכתוב ולסקור קוד אך עלול להחמיץ הרשאות, להמציא חבילות או לפרש תוכן זדוני כהוראות. משלבים סקירה אנושית, בדיקות הרשאות וסורקים המתאימים לסביבה.
מה עושים אם מפתח או מידע דלפו?
מבטלים מפתחות חשופים, מצמצמים גישה, שומרים ראיות ובודקים יומני פעילות. מתקנים את נתיב החשיפה ובודקים גיבוי ושחזור. מחיקת המפתח מהקוד בלבד אינה מבטלת אותו או מוחקת את ההיסטוריה.
