מילון האבטחה מסביר בעברית מה משמעות כל מונח, למה הוא חשוב ומה לבדוק. התחילו בהרשאות, RLS ומפתחות סודיים, והמשיכו למונחים של סביבת הפיתוח שלכם.
הכל WordPress PHP / Laravel Node.js / JS / TS Python .NET / C# Java / Spring Supabase / PostgreSQL Firebase SQL Server / Azure SQL MySQL / MariaDB MongoDB
לפי מספר (עולה) לפי מספר (יורד) לפי שם (א-ת) לפי שם (ת-א) הכל (189) מושגי יסוד (23) בקרת גישה והרשאות (21) Supabase, Lovable ונתונים (14) חולשות וסיכוני OWASP (34) בדיקות וכלי אבטחה (13) GitHub Security וקוד (11) Production ו-Go Live (16) Security Headers (12) דוחות ושירות ללקוח (11) WordPress (9) אבטחה לפי סביבת פיתוח (12) AI ו-LLM (9) פרטיות, גיבוי ותגובה לאירוע (6)
$ מציג 189 מתוך 189 מונחים
משטח תקיפה — Attack Surface Attack Surface
מה זה כל המקומות שדרכם משתמש, שירות חיצוני או תוקף פוטנציאלי יכולים לתקשר עם המערכת או להשפיע עליה.
למה זה חשוב באתרי Lovable/AI המשטח גדל מהר: טפסים, Login, Supabase, קבצים, דומיין, API ו-Webhooks יכולים להיווצר בלי שבונה האתר שם לב.
דוגמה פורטל עם טופס, אזור אישי, מסמכים ו-Admin Panel כולל יותר נקודות בדיקה מדף נחיתה פשוט.
מה לבדוק / איך למנוע ממפים את כל הכניסות למערכת: עמודים, טפסים, API, Storage, משתמשים, Roles וחיבורים חיצוניים. חזית האתר — Frontend Frontend
מה זה החלק שרץ בדפדפן של המשתמש: מסכים, JavaScript, רכיבי UI, בקשות Network וקוד צד לקוח.
למה זה חשוב כל מה שמגיע ל-Frontend נחשב גלוי למשתמש מבחינת אבטחה, גם אם לא מוצג בעיצוב.
דוגמה מידע שמוחזר ב-Network Response אבל מוסתר מהמסך עדיין נחשב חשוף.
מה לבדוק / איך למנוע פותחים DevTools ובודקים Console, Network, Local Storage ו-Cookies כדי לראות מה באמת מגיע לדפדפן. צד שרת — Backend Backend
מה זה הלוגיקה שרצה בצד שרת, API, Edge Function או שירות backend, ולא בדפדפן של המשתמש.
למה זה חשוב החלטות רגישות כמו הרשאות, פעולות אדמין וגישה לדאטה צריכות להיאכף בצד שרת או DB, לא רק במסך.
דוגמה כפתור “מחק משתמש” יכול להיות מוסתר ב-UI, אבל ה-Backend חייב לחסום פעולה כזו למי שאינו אדמין.
מה לבדוק / איך למנוע בודקים שהפעולה עצמה חסומה, לא רק שהכפתור אינו מופיע. ממשק תכנות יישומים — API API = Application Programming Interface
מה זה דרך מוסדרת שבה האתר מדבר עם שרת, Supabase או שירותים חיצוניים באמצעות בקשות ותשובות.
למה זה חשוב רבות מהחולשות לא נראות בעיצוב האתר אלא בבקשות API ובמידע שחוזר מהשרת.
דוגמה האתר מציג רק 3 שדות במסך, אבל Response של ה-API מחזיר גם אימייל, role ו-user_id של משתמשים אחרים.
מה לבדוק / איך למנוע בודקים Network/Fetch/XHR ורואים אילו Endpoints נקראים ומה חוזר מהם. נקודת קצה — Endpoint Endpoint
מה זה כתובת או פעולה ספציפית ב-API שמחזירה מידע או מבצעת פעולה.
למה זה חשוב כל Endpoint הוא נקודת בדיקה אפשרית: האם צריך Login? האם נבדקת הרשאה? האם הוא מחזיר יותר מדי מידע?
דוגמה /api/requests מחזיר רשימת בקשות; /api/admin/users אמור להיות נגיש רק לאדמין.
מה לבדוק / איך למנוע עוברים על ה-Endpoints שנראים ב-Network ומסמנים ציבורי/פרטי/אדמין. בקשה — Request Request
מה זה המידע שהדפדפן או כלי בדיקה שולחים לשרת או ל-API.
למה זה חשוב אפשר לשנות בקשה שנשלחת מהדפדפן, למשל מזהה משתמש או סכום לתשלום. השרת חייב לבדוק הרשאות וערכים בעצמו כדי למנוע שינוי נתונים של אחרים.
דוגמה בקשה לעדכון פרופיל מכילה owner_user_id שנשלח מהדפדפן; זה עלול להיות סימן לסיכון אם השרת סומך עליו.
מה לבדוק / איך למנוע מנתחים בקשות ב-DevTools או בכלי API ומוודאים שהשרת לא סומך על ערכים רגישים מהלקוח בלבד. תשובה — Response Response
מה זה המידע שהשרת מחזיר לדפדפן אחרי בקשה.
למה זה חשוב מידע שמוחזר מהשרת גלוי למשתמש גם אם המסך מסתיר אותו. תשובה עם פרטי לקוחות אחרים או מפתחות סודיים היא דליפת מידע.
דוגמה טופס יצירת קשר מחזיר debug_token, role ו-internal_id למשתמש.
מה לבדוק / איך למנוע בודקים Response Preview/Response ב-Network ומוודאים שחוזר רק מידע שהמשתמש באמת צריך לראות. קוד סטטוס — Status Code HTTP Status Code
מה זה מספר שמייצג את תוצאת הבקשה: הצלחה, חוסר הרשאה, שגיאה וכו׳.
למה זה חשוב קוד הסטטוס עוזר לבדוק אם השרת באמת חוסם גישה לא מורשית. גם כשמוחזר קוד שגיאה, צריך לוודא שהתשובה אינה כוללת מידע פרטי.
דוגמה 200 = הצליח; 401 = לא מחובר; 403 = אין הרשאה; 404 = לא נמצא; 500 = שגיאת שרת.
מה לבדוק / איך למנוע כשמשתמש לא מורשה ניגש למשאב פרטי, מצפים לחסימה ברורה כמו 403 או התנהגות שקולה — לא 200 עם מידע רגיש. אכיפה בצד לקוח — Client-Side Enforcement Client-Side Enforcement
מה זה הגנה שמתרחשת רק בדפדפן: הסתרת כפתור, תפריט, route או תנאי JavaScript.
למה זה חשוב זו שכבת UX, לא אבטחה מלאה. משתמש מתקדם או שגיאת לוגיקה יכולים לעקוף אותה.
דוגמה המערכת לא מציגה כפתור Admin למשתמש רגיל, אבל URL ישיר עדיין נפתח.
מה לבדוק / איך למנוע לא מסתפקים בבדיקת UI. בודקים ישירות שהמידע/פעולה חסומים בצד שרת או בסיס נתונים. אכיפה בצד שרת — Server-Side Enforcement Server-Side Enforcement
מה זה הגנה שנאכפת בשרת, API, Edge Function או בסיס הנתונים לפני שמידע חוזר למשתמש.
למה זה חשוב זו ההגנה החשובה באמת עבור הרשאות ודאטה רגיש.
דוגמה ה-API בודק שה-request.owner_user_id שווה למשתמש המחובר לפני החזרת פרטי הבקשה.
מה לבדוק / איך למנוע מנסים פעולה/גישה כמשתמש לא מורשה ומוודאים שהשרת לא מחזיר את המידע. אימות זהות — Authentication (AuthN) AuthN = Authentication
מה זה בדיקה מי המשתמש: האם הוא מחובר, מי הוא, ומה הזהות שלו במערכת.
למה זה חשוב Login הוא תנאי בסיסי, אבל הוא לא מספיק. אחרי שיודעים מי המשתמש צריך לבדוק מה מותר לו לעשות.
דוגמה דניאל התחבר בהצלחה למערכת.
מה לבדוק / איך למנוע בודקים Login/Logout, session, Reset Password, והאם עמודים פרטיים דורשים משתמש מחובר. הרשאה — Authorization (AuthZ) AuthZ = Authorization
מה זה בדיקה מה מותר למשתמש המחובר לראות או לבצע.
למה זה חשוב זה הלב של הקורס: גם משתמש מחובר לא אמור לראות הכל.
דוגמה דניאל מחובר, אבל אסור לו לראות בקשות של מאיה.
מה לבדוק / איך למנוע בודקים עם שני משתמשים לפחות ומשווים איזה מידע כל אחד רואה. סשן — Session Session
מה זה מצב התחברות מתמשך שמאפשר למערכת לזהות את המשתמש בין עמודים ובקשות.
למה זה חשוב אם session מנוהל לא נכון, משתמש יכול להישאר מחובר מדי, להיחסם לא נכון, או לאבד הרשאות בצורה מסוכנת.
דוגמה משתמש מתחבר פעם אחת ואז יכול לעבור בין Dashboard, מסמכים ופרופיל בלי להתחבר מחדש.
מה לבדוק / איך למנוע בודקים Logout, פתיחה בחלון פרטי, שינוי role, והאם session מתנהג בצורה צפויה. עוגייה — Cookie HTTP Cookie
מה זה פיסת מידע שהדפדפן שומר ושולח לאתר בבקשות עתידיות.
למה זה חשוב Cookies משמשות הרבה פעמים ל-session ולכן צריך להגן עליהן באמצעות הגדרות מתאימות.
דוגמה Cookie שמייצגת session של משתמש מחובר.
מה לבדוק / איך למנוע בודקים ב-Application > Cookies אם קיימות הגדרות כמו HttpOnly, Secure ו-SameSite כאשר רלוונטי. אחסון מקומי — Local Storage Local Storage
מה זה אזור אחסון בדפדפן שבו האתר יכול לשמור נתונים בצד לקוח.
למה זה חשוב כל מה שנשמר שם גלוי למשתמש בדפדפן. לא שמים שם secrets או מידע רגיש שלא צריך להיות נגיש.
דוגמה שמירת token רגיש או מידע פרטי מלא ב-Local Storage עלולה להיות בעייתית.
מה לבדוק / איך למנוע פותחים DevTools > Application > Local Storage ובודקים שאין שם secrets או מידע מיותר. טוקן — Token Security Token
מה זה ערך שמייצג זהות, הרשאה או גישה זמנית לשירות.
למה זה חשוב Tokens יכולים לתת גישה לפעולות או מידע. צריך להבין איפה הם נשמרים ומה היקף ההרשאה שלהם.
דוגמה Access token שמאפשר לקרוא API בשם המשתמש.
מה לבדוק / איך למנוע לא משתפים tokens, לא מדביקים אותם בצ׳אט, ובודקים שהם לא מודפסים ל-Console או ל-Response. טוקן JWT JWT = JSON Web Token
מה זה פורמט נפוץ לטוקן שיכול להכיל Claims על המשתמש, כמו מזהה, תפקיד וזמן תפוגה.
למה זה חשוב JWT עוזר להבין מי המשתמש, אבל אסור לסמוך על מידע מהדפדפן בלי אימות ואכיפה בצד שרת/DB.
דוגמה JWT עשוי להכיל user_id או role.
מה לבדוק / איך למנוע בודקים שהמערכת לא מאפשרת למשתמש לקבוע לעצמו role או user_id דרך הלקוח. תפקיד משתמש — Role Role
מה זה סיווג המשתמש לפי הרשאות או אחריות במערכת.
למה זה חשוב בפורטל Lovable מורכב, טעות ב-Role יכולה לפתוח אזורי ניהול או דאטה רגיש למשתמשים לא נכונים.
דוגמה User, Provider, Manager, Admin.
מה לבדוק / איך למנוע מגדירים טבלת הרשאות ברורה לכל Role ובודקים אותה בפועל עם משתמשי דמו. בקרת גישה לפי תפקידים — RBAC RBAC = Role-Based Access Control
מה זה מודל שבו הרשאות נקבעות לפי תפקיד המשתמש.
למה זה חשוב עוזר לעשות סדר באפליקציות עם User, Manager ו-Admin, אבל חייב להיות נאכף בפועל.
דוגמה Manager יכול לראות פניות, Admin יכול לנהל משתמשים, User רואה רק את עצמו.
מה לבדוק / איך למנוע בודקים שכל Role באמת מקבל רק את הפעולות והמידע שהוגדרו לו. עיקרון ההרשאה המינימלית — Least Privilege Principle of Least Privilege
מה זה כל משתמש, שירות או מפתח מקבל רק את ההרשאות הנדרשות לו — לא יותר.
למה זה חשוב מפחית נזק במקרה של טעות, פריצה או חשיפת key.
דוגמה נציג שירות לא צריך לראות את כל הטבלאות או לשנות הרשאות אדמין.
מה לבדוק / איך למנוע בכל Role וכל API key שואלים: האם ההרשאה הזו באמת נחוצה? בקרת גישה שבורה — Broken Access Control Broken Access Control
מה זה מצב שבו משתמש מצליח לגשת למידע או לבצע פעולה שלא אמורים להיות זמינים לו.
למה זה חשוב זה אחד הסיכונים המרכזיים באפליקציות עם משתמשים, ובמיוחד באפליקציות שנבנו מהר עם AI.
דוגמה משתמש רגיל רואה מסמך של משתמש אחר או נכנס למסך ניהול.
מה לבדוק / איך למנוע בודקים עם כמה משתמשים ו-Roles, ומוודאים שהחסימה נאכפת בצד שרת/DB. גישה לנתונים של משתמש אחר — IDOR / BOLA IDOR = Insecure Direct Object Reference / BOLA = Broken Object Level Authorization
מה זה חולשת הרשאות שבה שינוי מזהה בקישור או בפנייה לממשק מאפשר לקרוא או לשנות נתונים של משתמש אחר. בעולם API נהוג גם השם BOLA.
למה זה חשוב בפורטל לקוחות היא עלולה לחשוף חשבוניות ומסמכים גם למשתמש שהתחבר כחוק; סריקה ללא שני חשבונות עלולה לפספס אותה.
דוגמה דניאל משנה את מספר הבקשה בקישור או ב-API ומקבל את הבקשה של מאיה.
מה לבדוק / איך למנוע בודקים בחשבונות בדיקה נפרדים קריאה, שינוי ומחיקה של אותה רשומה. השרת ומדיניות RLS חייבים לבדוק הרשאה למשאב בכל פעולה. הרשאה שבורה ברמת פעולה — BFLA BFLA = Broken Function Level Authorization
מה זה מצב שבו משתמש יכול לבצע פעולה או לגשת לפונקציה שלא מתאימה לתפקיד שלו.
למה זה חשוב גם אם דאטה פרטי לא נחשף, פעולה רגישה כמו שינוי סטטוס או מחיקה יכולה להיות מסוכנת.
דוגמה משתמש רגיל מצליח לקרוא לפעולת admin/update-user-role.
מה לבדוק / איך למנוע בודקים פעולות לפי Role: מי יכול ליצור, לעדכן, למחוק, לאשר, לשנות סטטוס ולנהל משתמשים. בדיקת בעלות — Ownership Check Ownership Check
מה זה בדיקה שהמשאב המבוקש באמת שייך למשתמש המחובר או שהוא מורשה אליו.
למה זה חשוב זו ההגנה המרכזית נגד IDOR/BOLA.
דוגמה לפני החזרת בקשה, בודקים ש-owner_user_id תואם ל-user_id של המשתמש המחובר.
מה לבדוק / איך למנוע בכל עמוד Details או API by ID מוודאים שקיימת בדיקת ownership. ריבוי לקוחות במערכת אחת — Multi-Tenancy Multi-Tenancy
מה זה מצב שבו אותה מערכת משרתת כמה לקוחות, ארגונים או חשבונות נפרדים.
למה זה חשוב טעות בהפרדה בין tenants עלולה לחשוף מידע של לקוח אחד ללקוח אחר.
דוגמה סוכנות אחת רואה לידים של סוכנות אחרת באותו פורטל.
מה לבדוק / איך למנוע מוסיפים tenant_id/organization_id ובודקים בידוד דאטה בכל שאילתה, policy ו-API. בידוד דיירים/ארגונים — Tenant Isolation Tenant Isolation
מה זה הפרדה שמבטיחה שמשתמשים מארגון אחד לא יכולים לראות או לשנות מידע של ארגון אחר.
למה זה חשוב במערכות B2B זה קריטי לא פחות מהרשאות user_id.
דוגמה Manager של חברה א׳ לא אמור לראות מסמכים של חברה ב׳.
מה לבדוק / איך למנוע בודקים לפחות שני ארגונים נפרדים עם משתמשים שונים ומוודאים שאין זליגה ביניהם. לוגיקה עסקית — Business Logic Business Logic
מה זה החוקים העסקיים של האפליקציה: מי רשאי לעשות מה, באיזה מצב, ובאיזה סדר.
למה זה חשוב סריקות אבטחה טכניות לא תמיד מבינות את החוקים האלה ולכן עלולות לפספס חולשות.
דוגמה רק Manager יכול לאשר בקשה מעל סכום מסוים, אבל משתמש רגיל מצליח לשנות סטטוס ידנית.
מה לבדוק / איך למנוע מגדירים Abuse Cases ובודקים זרימות עסקיות רגישות עם Roles שונים. מקרה ניצול לרעה — Abuse Case Abuse Case
מה זה תרחיש שבו משתמש מנצל יכולת קיימת במערכת בצורה שלא התכוונו אליה.
למה זה חשוב עוזר לחשוב כמו בודק אבטחה בלי להיכנס להוראות תקיפה מסוכנות.
דוגמה משתמש שולח טופס שוב ושוב, או מנסה לראות בקשות של אחרים דרך מזהים.
מה לבדוק / איך למנוע כותבים לכל פיצ׳ר: מה שימוש תקין, ומה שימוש לרעה שצריך לחסום. מודל איומים — Threat Modeling Threat Modeling
מה זה תהליך חשיבה מסודר שממפה נכסים, משתמשים, איומים, נקודות כניסה והגנות.
למה זה חשוב באתרי AI זה מאפשר לעצור רגע לפני פרודקשן ולהבין מה באמת צריך לבדוק.
דוגמה מיפוי: יש מסמכים פרטיים, API, משתמשים, אדמין ו-Supabase — לכן צריך בדיקות הרשאה ו-Storage.
מה לבדוק / איך למנוע מכינים טבלת נכסים, משתמשים, תרחישי סיכון ובדיקות נדרשות. 31 Supabase, Lovable ונתונים
מערכת התחברות של Supabase — Supabase Auth Supabase Authentication
מה זה שירות האימות של Supabase לניהול הרשמה, התחברות, סשנים ומשתמשים.
למה זה חשוב Lovable משתמשת לעיתים ב-Supabase Auth, אבל Login בלבד לא מגן על הטבלאות ללא RLS/Policies.
דוגמה משתמש מחובר דרך Supabase Auth אך טבלת requests פתוחה מדי.
מה לבדוק / איך למנוע בודקים Auth Redirect URLs, משתמשי בדיקה, sessions והאם הרשאות הטבלאות מתבססות על המשתמש המחובר. 32 Supabase, Lovable ונתונים
אבטחה ברמת שורה — RLS RLS = Row Level Security
מה זה מנגנון שמאפשר לבסיס הנתונים להחזיר או לשנות רק שורות שהמשתמש מורשה אליהן.
למה זה חשוב זה אחד הכלים הכי חשובים למניעת חשיפת מידע בין משתמשים ב-Supabase.
דוגמה דניאל מקבל רק rows שבהן owner_user_id = user_a.
מה לבדוק / איך למנוע מוודאים ש-RLS פעיל בטבלאות רגישות ושקיימות policies מתאימות ל-SELECT/INSERT/UPDATE/DELETE. 33 Supabase, Lovable ונתונים
מדיניות הרשאה — Policy Database/RLS Policy
מה זה כלל שמגדיר מי יכול לקרוא, ליצור, לעדכן או למחוק מידע בטבלה.
למה זה חשוב Policy רחבה מדי יכולה להפוך טבלה פרטית לציבורית בפועל.
דוגמה User can read own requests; Admin can read all requests.
מה לבדוק / איך למנוע קוראים policies ומתרגמים אותן לעברית פשוטה: מי רשאי לעשות מה ובאיזה תנאי. 34 Supabase, Lovable ונתונים
טבלה ציבורית מול פרטית Public / Private Table
מה זה טבלה ציבורית מיועדת למידע שמותר לכולם לקרוא; טבלה פרטית מכילה מידע שהגישה אליו מוגבלת לפי משתמש, תפקיד או ארגון. שם הטבלה או סכמת public אינם קובעים את ההרשאות.
למה זה חשוב טבלת לידים או הזמנות שנפתחה בטעות לציבור חושפת פרטי לקוחות, גם אם אין קישור אליה במסך.
דוגמה מאמרים שפורסמו יכולים להיות ציבוריים; הודעות, מסמכים והזמנות צריכים הגבלת גישה.
מה לבדוק / איך למנוע מסווגים כל טבלה, בודקים הרשאות ו-RLS לקריאה, הוספה, שינוי ומחיקה כאורח וכמשתמש אחר, ומונעים חשיפת שדות אישיים בטבלה ציבורית. 36 Supabase, Lovable ונתונים
מפתח אנונימי — Anon Key Supabase Anonymous Key
מה זה מפתח ציבורי יחסית שמשמש את ה-Frontend כדי לתקשר עם Supabase תחת מגבלות RLS.
למה זה חשוב הוא יכול להופיע בצד לקוח, אבל לא אמור לאפשר גישה חופשית לדאטה. ההגנה האמיתית היא RLS.
דוגמה האפליקציה משתמשת ב-anon key לקריאת נתונים ציבוריים או נתונים מורשים.
מה לבדוק / איך למנוע בודקים שלא משתמשים ב-anon key כתחליף להרשאות וש-RLS אכן מגביל גישה. 37 Supabase, Lovable ונתונים
מפתח תפקיד שירות — Service Role Key Supabase Service Role Key
מה זה מפתח רגיש מאוד של Supabase שמסוגל לעקוף RLS ולבצע פעולות חזקות.
למה זה חשוב אסור שיופיע בצד לקוח. חשיפה שלו יכולה לאפשר גישה רחבה מאוד לדאטה.
דוגמה service_role key שמופיע בקוד frontend, ב-Console או ב-repository ציבורי.
מה לבדוק / איך למנוע אם נחשף: מחליפים key, בודקים שימושים, מעבירים לצד שרת/Environment Variables ומבצעים review. 38 Supabase, Lovable ונתונים
אחסון קבצים — Storage Bucket Storage Bucket / Public Bucket / Private Bucket
מה זה אזור אחסון קבצים. באזור ציבורי ניתן לקרוא קבצים ללא התחברות; באזור פרטי הקריאה מחייבת הרשאה או קישור חתום לזמן מוגבל. גם העלאה ומחיקה צריכות הרשאות.
למה זה חשוב מסמכי לקוחות באזור ציבורי נגישים לכל מי שמחזיק בקישור; קישור שקשה לנחש אינו הגנה.
דוגמה תמונות בלוג נשמרות באזור ציבורי, וחוזים באזור פרטי עם קישור זמני למשתמש מורשה.
מה לבדוק / איך למנוע ממפים ציבורי מול פרטי, בודקים גישה לקובץ של משתמש אחר, מגבילים העלאה ומחיקה ומוודאים שקישור חתום פוקע ושנוצר רק למורשה. 41 Supabase, Lovable ונתונים
קישור חתום — Signed URL Signed URL
מה זה קישור זמני ומוגבל לקובץ פרטי.
למה זה חשוב מאפשר לתת גישה לקובץ בלי להפוך את כל ה-bucket לציבורי.
דוגמה קישור למסמך תקף ל-10 דקות למשתמש מורשה.
מה לבדוק / איך למנוע בודקים שהקישור מוגבל בזמן, לא נוצר למי שאינו מורשה, ולא נשמר במקומות ציבוריים. 42 Supabase, Lovable ונתונים
פונקציית קצה — Edge Function Edge Function
מה זה פונקציה שרצה בצד שרת/Edge ומבצעת לוגיקה או תקשורת עם שירותים חיצוניים.
למה זה חשוב מקום נכון לשים פעולות רגישות, אבל חייב לכלול בדיקת auth/authorization.
דוגמה Edge Function ששולחת אימייל או מעדכנת סטטוס בקשה.
מה לבדוק / איך למנוע בודקים שהיא דורשת משתמש/Role מתאים ולא מחזירה מידע פנימי מיותר. 43 Supabase, Lovable ונתונים
משתני סביבה — Environment Variables (ENV) ENV = Environment Variables
מה זה הגדרות ומפתחות שנשמרים מחוץ לקוד, לפי סביבת הרצה.
למה זה חשוב עוזרים להפריד secrets מהקוד ולנהל Preview/Production בצורה בטוחה.
דוגמה SUPABASE_URL, SUPABASE_ANON_KEY, STRIPE_SECRET_KEY.
מה לבדוק / איך למנוע מוודאים שמפתחות רגישים נמצאים רק בסביבת שרת/Platform ולא בקוד צד לקוח. 44 Supabase, Lovable ונתונים
Webhook Webhook
מה זה קריאה אוטומטית משירות חיצוני לאפליקציה כאשר קורה אירוע.
למה זה חשוב Webhook לא מאומת יכול לאפשר עדכון מידע לא מורשה או קבלת אירועים מזויפים.
דוגמה שירות תשלומים שולח הודעה שהעסקה הצליחה.
מה לבדוק / איך למנוע בודקים חתימה/secret של webhook, ולוגיקה שמוודאת שהאירוע אמיתי ורלוונטי. OWASP Top 10 OWASP = Open Worldwide Application Security Project Top 10
מה זה רשימת סיכוני אבטחת Web מרכזיים שמפורסמת על ידי OWASP ומשמשת כנקודת ייחוס מקצועית.
למה זה חשוב נותנת שפה מקצועית לקורס ומחברת בעיות כמו Broken Access Control, Injection ו-Security Misconfiguration לעולם מוכר.
דוגמה Broken Access Control הוא אחד הסיכונים המרכזיים ברשימה.
מה לבדוק / איך למנוע משתמשים ברשימה כמפה, אבל מתמקדים במה שרלוונטי לאתרי AI ו-Lovable. הזרקה — Injection Injection
מה זה מצב שבו קלט משתמש משפיע בצורה לא בטוחה על שאילתה, פקודה, Prompt או פעולה פנימית.
למה זה חשוב כל מקום שבו משתמש מזין טקסט או קובץ הוא נקודת בדיקה.
דוגמה טופס שמכניס קלט ישירות לשאילתה או ל-Prompt ללא בקרה מתאימה.
מה לבדוק / איך למנוע משתמשים ב-validation, sanitization, ספריות בטוחות, הרשאות מוגבלות ובדיקות קלט. לא מדגימים ניצול לא מורשה. הזרקת SQL — SQL Injection (SQLi) SQLi = Structured Query Language Injection
מה זה סוג של Injection שבו קלט משפיע על שאילתת SQL בצורה שעלולה לחשוף או לשנות מידע.
למה זה חשוב פחות נפוץ אם עובדים נכון עם Supabase/ORM, אבל חשוב להכיר כשיש שאילתות ידניות.
דוגמה קלט מטופס נכנס לשאילתת SQL ללא פרמטרים בטוחים.
מה לבדוק / איך למנוע משתמשים בשאילתות פרמטריות, APIs בטוחים ו-RLS; לא בונים SQL מקלט גולמי. הזרקת פקודות — Command Injection Command Injection
מה זה מצב שבו קלט משתמש מגיע לפקודת מערכת או סקריפט בצורה לא בטוחה.
למה זה חשוב רלוונטי יותר כשאפליקציה מפעילה פעולות שרת, קבצים או סקריפטים.
דוגמה שדה קלט שמשפיע על פקודת מערכת בצד שרת.
מה לבדוק / איך למנוע לא מעבירים קלט גולמי לפקודות, מגבילים הרשאות, ומעדיפים APIs בטוחים. הזרקת פרומפט — Prompt Injection Prompt Injection
מה זה מצב שבו קלט משתמש משנה את התנהגות מודל AI או גורם לו להתעלם מהנחיות.
למה זה חשוב חשוב לאפליקציות שמשלבות AI, Claude Code או שירותי LLM.
דוגמה משתמש מזין טקסט שגורם למערכת AI להחזיר מידע או לבצע פעולה שלא התכוונו אליה.
מה לבדוק / איך למנוע מפרידים בין נתוני משתמש להוראות מערכת, מגבילים פעולות, לא נותנים למודל גישה חופשית ל-secrets, ומאמתים תוצאות בצד שרת. אבטחת סקילים — מקורות מהימנים וכלי בדיקה סקריפטינג בין אתרים — XSS XSS = Cross-Site Scripting
מה זה חולשה שבה תוכן לא בטוח שמקורו במשתמש מוצג או מורץ אצל משתמשים אחרים.
למה זה חשוב באתרים עם תוכן משתמשים, הודעות, תגובות או תיאורים, זה סיכון נפוץ.
דוגמה משתמש מזין תוכן שמוצג לאחרים בלי ניקוי מתאים.
מה לבדוק / איך למנוע משתמשים ב-escaping, sanitization, frameworks בטוחים ו-CSP. בודקים שדות שמוצגים חזרה למשתמשים. זיוף בקשה בין אתרים — CSRF CSRF = Cross-Site Request Forgery
מה זה מצב שבו אתר חיצוני גורם לדפדפן של משתמש מחובר לבצע פעולה באתר אחר.
למה זה חשוב רלוונטי בעיקר כאשר פעולות מבוססות cookies/session ללא הגנות מתאימות.
דוגמה משתמש מחובר, ואתר אחר מנסה לגרום לדפדפן שלו לשלוח פעולה רגישה.
מה לבדוק / איך למנוע בודקים שימוש ב-SameSite cookies, CSRF tokens או מנגנוני auth שמתאימים לארכיטקטורה. זיוף בקשה מצד שרת — SSRF SSRF = Server-Side Request Forgery
מה זה מצב שבו השרת נגרם לגשת לכתובות או שירותים שלא אמור לגשת אליהם.
למה זה חשוב רלוונטי אם האתר מקבל URL מהמשתמש ומוריד/קורא ממנו תוכן בצד שרת.
דוגמה שדה “ייבוא מקישור” שגורם לשרת לגשת לכתובות פנימיות.
מה לבדוק / איך למנוע מגבילים כתובות מותרות, חוסמים רשתות פנימיות, ולא סומכים על URLs מקלט משתמש. הגדרות אבטחה שגויות — Security Misconfiguration Security Misconfiguration
מה זה הגדרה לא נכונה של שרת, DB, Storage, Headers, CORS, Debug או הרשאות.
למה זה חשוב באתרי AI זה נפוץ כי הרבה הגדרות נוצרות מהר או נשארות ברירת מחדל.
דוגמה RLS כבוי, bucket ציבורי, CORS פתוח מדי, debug פעיל בפרודקשן.
מה לבדוק / איך למנוע משתמשים בצ׳קליסט Production, SecurityHeaders, Supabase Advisor ובדיקות ידניות. רכיבים פגיעים או מיושנים — Vulnerable and Outdated Components Vulnerable and Outdated Components
מה זה ספריות, חבילות או רכיבים עם חולשות ידועות או גרסאות ישנות.
למה זה חשוב רלוונטי במיוחד כשיש GitHub/package.json ותלויות npm.
דוגמה חבילת npm עם CVE פעיל.
מה לבדוק / איך למנוע בודקים Dependabot/SCA, מעדכנים גרסאות, ובודקים שהעדכון לא שובר את האתר. כשלי זיהוי ואימות — Identification and Authentication Failures Identification and Authentication Failures
מה זה בעיות במנגנוני Login, Session, Reset Password, MFA וניהול משתמשים.
למה זה חשוב גם אם הרשאות נכונות, Auth חלש עלול לאפשר כניסה או שימוש לא רצוי.
דוגמה Reset password לא מוגדר נכון או session לא פוקע.
מה לבדוק / איך למנוע בודקים זרימות Login/Logout/Reset, חוזק סיסמאות, MFA אם רלוונטי והתנהגות session. כשלי קריפטוגרפיה — Cryptographic Failures Cryptographic Failures
מה זה בעיות בהצפנה, שמירת מידע רגיש, TLS, סיסמאות או העברת מידע.
למה זה חשוב בדרך כלל בקורס הזה ניגע בזה ברמת Production: HTTPS, secrets ומידע רגיש.
דוגמה אתר ללא HTTPS או מידע אישי שנשלח/נשמר בלי הגנה מתאימה.
מה לבדוק / איך למנוע מוודאים HTTPS/TLS, לא שומרים סודות בדפדפן, ומשתמשים בשירותי Auth מוכרים במקום פתרונות מאולתרים. כשלי שלמות תוכנה ודאטה — Software and Data Integrity Failures Software and Data Integrity Failures
מה זה סיכונים שנובעים מתהליך build/deploy לא בטוח, dependencies לא מאומתות או שרשרת אספקה.
למה זה חשוב רלוונטי לפרויקטים עם GitHub, CI/CD וחבילות צד שלישי.
דוגמה עדכון dependency לא מבוקר מכניס התנהגות לא רצויה.
מה לבדוק / איך למנוע משתמשים ב-PR review, Dependabot, lock files וסריקות לפני deploy. כשלי ניטור ורישום — Security Logging and Monitoring Failures Security Logging and Monitoring Failures
מה זה חוסר יכולת לדעת מה קרה במערכת אחרי אירוע, שגיאה או ניסיון גישה חריג.
למה זה חשוב בלי logs/monitoring קשה לגלות בעיות או להבין השפעה.
דוגמה אין תיעוד של ניסיונות כניסה או גישה לעמודים רגישים.
מה לבדוק / איך למנוע מגדירים logs בסיסיים, error tracking והתראות לאירועים חריגים בפרודקשן. חשיפת סודות — Secrets Exposure Secrets Exposure
מה זה מצב שבו מפתחות, tokens, סיסמאות או credentials מופיעים במקום גלוי או לא מוגן.
למה זה חשוב אחת הבעיות הכי מסוכנות בפרויקטים שנבנים מהר, במיוחד עם AI ו-GitHub.
דוגמה OpenAI key או Supabase service role key מופיע ב-Frontend או repo.
מה לבדוק / איך למנוע מריצים secret scanning, בודקים ENV, מחליפים מפתחות שנחשפו, ומעבירים סודות לצד שרת. חשיפת מידע — Information Disclosure Information Disclosure
מה זה החזרת או הצגת מידע שלא אמור להיות גלוי למשתמש.
למה זה חשוב זה יכול להיות מידע אישי, debug data, IDs, roles, הודעות שגיאה, paths פנימיים או תגובות API רחבות מדי.
דוגמה Response של טופס מחזיר internal_id ו-debug_token.
מה לבדוק / איך למנוע בודקים Responses, Console, error messages ועמודים פרטיים. מחזירים רק מידע שנדרש להצגה. מצב Debug פעיל — Debug Mode Debug Mode
מה זה מצב פיתוח שמציג מידע פנימי או מפורט מדי.
למה זה חשוב בפרודקשן זה עלול לחשוף פרטים טכניים שמסייעים להבין את המערכת.
דוגמה שגיאה באתר מציגה stack trace או משתני סביבה.
מה לבדוק / איך למנוע מוודאים ש-debug כבוי בפרודקשן וששגיאות מוצגות בצורה כללית למשתמש. טיפול בשגיאות — Error Handling Error Handling
מה זה האופן שבו המערכת מציגה ומתעדת שגיאות.
למה זה חשוב שגיאות צריכות לעזור למשתמש בלי לחשוף מידע פנימי.
דוגמה במקום “Database connection failed at...” מציגים “אירעה שגיאה, נסו שוב מאוחר יותר”.
מה לבדוק / איך למנוע בודקים טפסים ופעולות כושלות ורואים מה מוצג במסך ומה נרשם בלוגים. הגבלת קצב — Rate Limiting Rate Limiting
מה זה הגבלת כמות בקשות שמשתמש/כתובת יכולים לבצע בזמן מסוים.
למה זה חשוב חשוב לטפסים, Login, API ופעולות יקרות כדי לצמצם abuse וספאם.
דוגמה טופס שניתן לשלוח מאות פעמים בדקה ללא מגבלה.
מה לבדוק / איך למנוע מוסיפים מגבלות לפי IP/משתמש/פעולה, CAPTCHA במידת הצורך, וניטור חריגות. ניסיונות התחברות חוזרים — Brute Force Brute Force
מה זה ניסיון שיטתי לנחש סיסמאות או codes באמצעות הרבה ניסיונות.
למה זה חשוב רלוונטי ל-Login, reset codes וטפסים רגישים.
דוגמה אין הגבלה על ניסיונות התחברות כושלים.
מה לבדוק / איך למנוע מוסיפים rate limiting, lockout זהיר, MFA והתראות לניסיונות חריגים. שיתוף משאבים בין מקורות — CORS CORS = Cross-Origin Resource Sharing
מה זה מנגנון דפדפן שמגדיר מאילו דומיינים מותר לקרוא למשאבים/ API.
למה זה חשוב CORS חשוב אבל אינו תחליף להרשאות. גם API עם CORS “סגור” חייב לבדוק משתמש ו-Role.
דוגמה Access-Control-Allow-Origin: * על API רגיש יכול להיות סימן להגדרה רחבה מדי.
מה לבדוק / איך למנוע בודקים CORS ב-headers ומוודאים שאין הסתמכות עליו במקום AuthZ אמיתי. בדיקת אבטחה סטטית — SAST SAST = Static Application Security Testing / Code Scanning
מה זה ניתוח קוד בלי להריץ את האתר, המכונה גם Code Scanning, שמחפש דפוסים כמו הזרקות וטיפול לא בטוח בקלט.
למה זה חשוב קוד שה-AI יצר עלול לכלול נתיב מסוכן שלא נראה במסך; סריקה בכל שינוי יכולה לגלות אותו לפני פרסום.
דוגמה CodeQL או Semgrep מציגים התראה על קלט משתמש שמגיע לפקודת שרת.
מה לבדוק / איך למנוע מפעילים סריקה במאגר ובכל בקשת מיזוג, מאמתים התראות, מתקנים ומריצים שוב. סריקה נקייה אינה מחליפה בדיקת הרשאות עסקיות. בדיקת אבטחה דינמית — DAST DAST = Dynamic Application Security Testing
מה זה בדיקה של האפליקציה כשהיא רצה, מבחוץ, דרך HTTP ודפדפן.
למה זה חשוב שימושי גם בלי גישה לקוד, אבל לא תמיד מזהה לוגיקה עסקית והרשאות בין משתמשים.
דוגמה ZAP בודק headers, קונפיגורציות ובעיות נפוצות באתר חי או staging.
מה לבדוק / איך למנוע מריצים רק על אתר בבעלותך/באישור, קוראים תוצאות בזהירות ומאמתים ידנית. בדיקת אבטחה אינטראקטיבית — IAST IAST = Interactive Application Security Testing
מה זה בדיקה שמשלבת מידע מהאפליקציה בזמן ריצה עם ניתוח פנימי.
למה זה חשוב IAST יכול לזהות מסלול שבו קלט לא בטוח מגיע לשאילתה או לפעולה רגישה בזמן בדיקות. הוא מוסיף מידע פנימי שסורק חיצוני עלול לפספס, אך אינו מחליף בדיקת הרשאות.
דוגמה כלי שמזהה בעיות בזמן שהאפליקציה מופעלת בבדיקות.
מה לבדוק / איך למנוע להציג כמושג מתקדם, לא חובה ליישום במחזור הראשון. ניתוח רכיבי תוכנה — SCA SCA = Software Composition Analysis / Dependency Scanning
מה זה סריקת החבילות שהאתר תלוי בהן, כולל תלויות עקיפות, מול מאגרי חולשות ידועות. נקראת גם Dependency Scanning.
למה זה חשוב חבילה פגיעה יכולה לסכן את האתר גם כשהקוד שלכם תקין; קובץ הנעילה עשוי לשמור גרסה ישנה שלא רואים ברשימה הראשית.
דוגמה Dependabot או npm audit מזהים חבילה עקיפה עם חולשה וגרסת תיקון.
מה לבדוק / איך למנוע מריצים סריקה אוטומטית עם קובץ הנעילה, בודקים אם הגרסה הפגיעה בשימוש, משדרגים לגרסה מתוקנת ובודקים שהאתר עדיין עובד. סריקת סודות — Secret Scanning Secret Scanning
מה זה חיפוש מפתחות, tokens ו-credentials בקוד, היסטוריית Git או קבצים.
למה זה חשוב קריטי כשעובדים עם AI שמייצר קוד ועלול לשלב מפתחות במקומות לא נכונים.
דוגמה GitHub מזהה API key שהועלה ל-repository.
מה לבדוק / איך למנוע מחליפים מפתח שנחשף, מסירים מהקוד, מוסיפים ל-ENV ומוודאים שלא נשאר בהיסטוריה רלוונטית. סריקת חולשות — Vulnerability Scanning Vulnerability Scanning
מה זה בדיקה אוטומטית שמחפשת חולשות או הגדרות בעייתיות.
למה זה חשוב שימושית להתחלה, אך לא מחליפה בדיקת הרשאות ולוגיקה עסקית.
דוגמה SecurityHeaders מוצא headers חסרים; ZAP מוצא בעיות נפוצות.
מה לבדוק / איך למנוע משלבים סריקה עם בדיקה ידנית ודוח מסודר. בדיקת חדירות — Penetration Testing (Pentest) Pentest = Penetration Test
מה זה בדיקה מקצועית ומעמיקה שמנסה לזהות ולנצל חולשות בסביבה מורשית.
למה זה חשוב הקורס לא מחליף pentest מלא, אלא מלמד בדיקות מוכנות בסיסיות/בינוניות.
דוגמה מערכת עם תשלומים, דאטה רגיש או לקוחות רבים עשויה לדרוש pentest מקצועי.
מה לבדוק / איך למנוע מגדירים Scope, אישור כתוב, גבולות, ודוח. בקורס נשארים בהדגמות מעבדה ובדיקות הגנתיות. בדיקה ידנית — Manual Review Manual Security Review
מה זה בדיקה אנושית של התנהגות, הרשאות, לוגיקה, דוחות וכלים.
למה זה חשוב קריטית כי כלים אוטומטיים לא תמיד מבינים מי אמור לראות מה.
דוגמה בדיקה עם דניאל ומאיה כדי לוודא שאין חשיפת מידע בין משתמשים.
מה לבדוק / איך למנוע משלבים checklist, כמה משתמשי בדיקה, DevTools ודוח ממצאים. ממצא שווא — False Positive False Positive
מה זה ממצא שכלי מסמן כבעיה, אבל בפועל אינו מהווה סיכון אמיתי בהקשר הנבדק.
למה זה חשוב מונע פאניקה ומלמד לקרוא תוצאות בצורה מקצועית.
דוגמה כלי מסמן header חסר כחמור, אבל האתר הוא דמו פנימי ללא exposure ציבורי.
מה לבדוק / איך למנוע מאמתים כל ממצא, מתעדים החלטה, ולא מעבירים ללקוח רעש מיותר. בעיה שלא זוהתה — False Negative False Negative
מה זה בעיה אמיתית שהכלי לא מצא.
למה זה חשוב חשוב להסביר למה “הסריקה יצאה נקייה” לא שווה “האתר בטוח”.
דוגמה סורק לא מצא IDOR כי לא יודע שמאיה ודניאל משתמשים שונים.
מה לבדוק / איך למנוע מבצעים בדיקות ידניות ללוגיקה עסקית והרשאות גם אחרי סריקה אוטומטית. רמת חומרה — Severity Severity
מה זה דירוג טכני/מקצועי של חומרת ממצא.
למה זה חשוב עוזר לתעדף טיפול ולהסביר ללקוח מה דחוף.
דוגמה Critical, High, Medium, Low, Info.
מה לבדוק / איך למנוע מדרגים לפי השפעה, סבירות, נגישות, היקף מידע וקלות ניצול. סיכון — Risk Risk / Impact / Likelihood / Exploitability
מה זה דרך להעריך מה לתקן קודם: סיכון = השפעה × סבירות. ההשפעה היא הנזק לעסק וללקוחות; הסבירות היא הסיכוי שזה יקרה. קלות הניצול משפיעה על הסבירות, לצד החשיפה והתנאים הנדרשים.
למה זה חשוב חשיפת חוזים בקישור ציבורי דורשת טיפול דחוף יותר מתקלה שקשה להגיע אליה ושאינה חושפת מידע; התעדוף קובע איפה להשקיע זמן.
דוגמה מסמך לקוח שנגיש בשינוי מספר פשוט: נזק לפרטיות, חשיפה רחבה וקלות ניצול גבוהה.
מה לבדוק / איך למנוע לכל ממצא רושמים איזה מידע או כסף בסיכון, מי יכול להגיע אליו, כמה קל לנצל ומה יקטין את הסיכון; משתמשים בנוסחה ככלי הערכה ולא כחישוב ודאי. מאגר קוד — Repository (Repo) Repo = Repository
מה זה מקום שבו נשמר הקוד, ההיסטוריה, ההגדרות ולעיתים גם קבצי הפרויקט.
למה זה חשוב אם פרויקט Lovable/Claude Code מחובר ל-GitHub, אפשר להוסיף בדיקות קוד ותלויות.
דוגמה Repo שמכיל package.json, src, env example ו-README.
מה לבדוק / איך למנוע בודקים הרשאות repo, visibility, Security tab, secrets ותלויות. ענף קוד — Branch Branch
מה זה קו עבודה נפרד בקוד, למשל main, staging או feature/security-fix.
למה זה חשוב ענף נפרד מאפשר לבדוק תיקוני אבטחה לפני שהם מגיעים לאתר הפעיל. הגנה על הענף הראשי וסקירת שינויים מצמצמות הכנסת קוד מסוכן או ביטול הרשאות בטעות.
דוגמה תיקון RLS או route protection נעשה ב-branch נפרד.
מה לבדוק / איך למנוע עובדים ב-branch, בודקים, ואז ממזגים ל-main אחרי review. קומיט — Commit Commit
מה זה שמירת שינוי בהיסטוריית Git.
למה זה חשוב היסטוריית commit יכולה להכיל בטעות secrets ולכן חשוב scanning.
דוגמה commit ישן הכיל API key שנמחק אחר כך מהקובץ, אבל עדיין קיים בהיסטוריה.
מה לבדוק / איך למנוע מריצים secret scanning ומתייחסים לסוד שנכנס להיסטוריה כחשוף. בקשת מיזוג — Pull Request (PR) PR = Pull Request
מה זה תהליך שמאפשר לבדוק שינוי לפני מיזוגו לענף הראשי.
למה זה חשוב מקום טוב להריץ בדיקות אבטחה, review וסריקות לפני production.
דוגמה PR שמתקן הרשאות ומראה בדיקות חוזרות.
מה לבדוק / איך למנוע מוסיפים checklist ל-PR: AuthZ, RLS, secrets, dependencies, tests. לשונית אבטחה בגיטהאב — GitHub Security Tab GitHub Security Tab / GHAS = GitHub Advanced Security
מה זה לשונית שמרכזת התראות על תלויות, סודות וקוד במאגר GitHub. יכולות מתקדמות ממשפחת GHAS עשויות להיות תלויות בסוג המאגר, בתוכנית וברישוי.
למה זה חשוב התראה על מפתח שנחשף או חבילה פגיעה מחייבת טיפול גם אם האתר עובד; לשונית ריקה עלולה פשוט להעיד שהסריקות לא הופעלו.
דוגמה Dependabot מסמן תלות פגיעה וסריקת סודות מזהה מפתח שהועלה למאגר.
מה לבדוק / איך למנוע בודקים אילו יכולות זמינות ומופעלות במאגר, מוודאים שהסריקות באמת רצות ומטפלים בהתראות; אין חובה לרכוש GHAS כדי להתחיל בבדיקות בסיסיות. התראות Dependabot — Dependabot Alerts Dependabot Alerts
מה זה התראות של GitHub על dependencies עם חולשות ידועות או עדכונים מומלצים.
למה זה חשוב עוזר לבוני AI להבין שהבעיה לא תמיד בקוד שהם כתבו אלא בספריות צד שלישי.
דוגמה Dependabot מסמן חבילת npm בגרסה פגיעה.
מה לבדוק / איך למנוע בודקים severity, גרסה מתוקנת, השפעה על הפרויקט ומבצעים update/test. מנוע סריקת קוד של GitHub — CodeQL CodeQL = Code Query Language
מה זה כלי/שפה של GitHub לסריקת קוד ולזיהוי דפוסים בעייתיים.
למה זה חשוב רלוונטי למסלול GitHub מתקדם בקורס.
דוגמה CodeQL alert על שימוש לא בטוח בנתוני משתמש.
מה לבדוק / איך למנוע קוראים alert, בודקים אם רלוונטי, מתקנים ומבצעים סריקה חוזרת. ייעוץ אבטחה — Security Advisory Security Advisory
מה זה פרסום או התראה על חולשה ידועה בספרייה או מוצר.
למה זה חשוב עוזר להבין למה כלי SCA מסמן dependency.
דוגמה ספרייה מפרסמת advisory שממליץ לשדרג לגרסה חדשה.
מה לבדוק / איך למנוע קוראים summary, affected versions, patched versions ומעדכנים בהתאם. מזהה חולשה רשמי — CVE CVE = Common Vulnerabilities and Exposures
מה זה מזהה רשמי לחולשת אבטחה ידועה.
למה זה חשוב נותן דרך מקצועית להתייחס לחולשות בספריות ותשתיות.
דוגמה CVE-2025-XXXX מסמן חולשה ידועה בחבילה.
מה לבדוק / איך למנוע בודקים אם הפרויקט משתמש בגרסה מושפעת ומה גרסת התיקון. ציון חומרה לחולשה — CVSS CVSS = Common Vulnerability Scoring System
מה זה שיטת ניקוד לחומרת חולשות, בדרך כלל מ-0 עד 10.
למה זה חשוב עוזר להבין חומרת dependency alert, אך לא מחליף הערכת הקשר עסקי.
דוגמה CVSS 9.8 נשמע חמור, אבל צריך לבדוק אם החבילה מופעלת במסלול רלוונטי.
מה לבדוק / איך למנוע משלבים CVSS עם exposure, שימוש בפועל ויכולת תיקון. רשימת רכיבי תוכנה — SBOM SBOM = Software Bill of Materials
מה זה רשימה מסודרת של רכיבים ותלויות בפרויקט.
למה זה חשוב מושג מתקדם אך שימושי להבנת supply chain בפרויקטים גדולים.
דוגמה מסמך שמפרט אילו חבילות וגרסאות קיימות בפרויקט.
מה לבדוק / איך למנוע להכיר כמושג, לא חובה ליישום בקורס ראשון. סביבת ייצור — Production Prod = Production Environment
מה זה הסביבה האמיתית שבה משתמשים אמיתיים עובדים עם האתר.
למה זה חשוב מה שעובד ב-Preview לא תמיד מוכן ל-Production מבחינת הרשאות, ENV, דומיין ו-Auth URLs.
דוגמה האתר עלה ל-domain אמיתי ומקבל פניות של לקוחות.
מה לבדוק / איך למנוע לפני Production עוברים checklist: Auth, Supabase, ENV, headers, טפסים, SEO ודומיין. סביבת בדיקה — Preview / Staging Preview or Staging Environment
מה זה סביבה לבדיקה לפני Production.
למה זה חשוב מקום בטוח להריץ דמו, בדיקות ותיקונים בלי לפגוע במשתמשים אמיתיים.
דוגמה Vercel Preview או staging subdomain.
מה לבדוק / איך למנוע מריצים בדיקות על staging ומוודאים שאין דאטה אמיתי או סודות חשופים. בנייה — Build Build Process
מה זה תהליך הכנת האפליקציה להרצה: bundling, compiling, optimization.
למה זה חשוב בזמן הבנייה מפתחות סודיים עלולים להיכנס לקובצי הקוד שנשלחים לדפדפן. כל משתמש יכול לקרוא אותם, ולכן חשוב לבדוק שסודות נשארים רק בשרת.
דוגמה Build נכשל כי חסר Environment Variable בפרודקשן.
מה לבדוק / איך למנוע בודקים build logs, משתני סביבה ותלויות לפני Go Live. פריסה — Deployment Deployment
מה זה העלאת גרסה של האתר לסביבה פעילה.
למה זה חשוב פריסה עלולה להעלות לאתר הפעיל הרשאות שגויות, מצב בדיקה או גרסה עם חולשה. בדיקות לפני ואחרי הפריסה ואפשרות לחזור לגרסה קודמת מצמצמות את הנזק.
דוגמה Deploy ל-Vercel אחרי תיקון הרשאות.
מה לבדוק / איך למנוע מגדירים תהליך מסודר: staging, בדיקות, deploy, smoke test ו-retest. חזרה לגרסה קודמת — Rollback Rollback
מה זה החזרת האתר לגרסה קודמת במקרה שגרסה חדשה יצרה תקלה.
למה זה חשוב חלק חשוב מניהול סיכונים בפרודקשן.
דוגמה אחרי deploy נשבר Login, חוזרים לגרסה יציבה.
מה לבדוק / איך למנוע מוודאים שיש יכולת rollback ותיעוד של הגרסה האחרונה התקינה. לוגים — Logs Logs
מה זה רישומים של אירועים, שגיאות, בקשות ופעולות במערכת.
למה זה חשוב עוזרים להבין תקלות, ניסיונות גישה ובעיות אחרי השקה.
דוגמה לוג של 403 repeated על Admin route.
מה לבדוק / איך למנוע שומרים לוגים שימושיים בלי לחשוף secrets או מידע אישי מיותר. ניטור — Monitoring Monitoring
מה זה מעקב אחרי זמינות, ביצועים, שגיאות ואירועים חריגים.
למה זה חשוב אחרי Go Live צריך לדעת אם טפסים נשברים, login נכשל או יש שגיאות רבות.
דוגמה התראה על עלייה בשגיאות 500 אחרי deploy.
מה לבדוק / איך למנוע מגדירים error tracking, uptime monitoring והתראות בסיסיות. התראות — Alerting Alerting
מה זה מנגנון שמודיע כשקורה אירוע חריג או תקלה.
למה זה חשוב בלי התראות, בעיות בפרודקשן יכולות להישאר ימים בלי טיפול.
דוגמה התראה כשיש הרבה ניסיונות Login כושלים או טופס מפסיק לעבוד.
מה לבדוק / איך למנוע מגדירים התראות למדדים חשובים ולא מציפים ברעש. חומת אש לאפליקציות — WAF WAF = Web Application Firewall
מה זה שכבת הגנה לפני האתר שיכולה לחסום בקשות חשודות או דפוסי תקיפה נפוצים.
למה זה חשוב מושג חשוב, אבל לא תחליף לתיקון הרשאות וקוד.
דוגמה WAF עשוי לחסום בקשות אוטומטיות חשודות.
מה לבדוק / איך למנוע להכיר כשכבת הגנה נוספת; לא לסמוך עליו במקום RLS/AuthZ נכון. מערכת שמות דומיין — DNS DNS = Domain Name System
מה זה המערכת שמחברת דומיין לשרת/שירות כמו Vercel.
למה זה חשוב רשומת DNS שנשארה מחוברת לשירות שכבר נמחק עלולה לאפשר השתלטות על תת-דומיין. גניבת חשבון ניהול הדומיין עלולה גם להפנות לקוחות לאתר מתחזה.
דוגמה A/CNAME שמפנה דומיין ל-Vercel.
מה לבדוק / איך למנוע בודקים רשומות DNS, דומיין, SSL ו-redirects כחלק מ-Go Live. תקשורת מוצפנת — HTTPS / TLS TLS = Hypertext Transfer Protocol Secure / Transport Layer Security
מה זה הצפנת התקשורת בין הדפדפן לאתר.
למה זה חשוב בסיס חובה לכל אתר עם Login, טפסים או מידע אישי.
דוגמה אתר Production חייב להיפתח עם https:// ולא http://.
מה לבדוק / איך למנוע בודקים שה-HTTPS פעיל, התעודה תקינה ואין mixed content. תעודת SSL/TLS — SSL Certificate SSL = Secure Sockets Layer Certificate
מה זה תעודה שמאפשרת לדפדפן לאמת את האתר ולהצפין תעבורה.
למה זה חשוב למרות שהמונח SSL ישן, משתמשים בו עדיין בשפה יומיומית.
דוגמה Vercel מנפיק תעודת TLS לדומיין.
מה לבדוק / איך למנוע בודקים תוקף תעודה, התאמה לדומיין וחידוש אוטומטי. רשת הפצת תוכן — CDN CDN = Content Delivery Network
מה זה שירות שמפיץ תוכן דרך שרתים קרובים למשתמשים ולעיתים מוסיף שכבות אבטחה.
למה זה חשוב אם ה-CDN שומר תשובה פרטית במטמון ציבורי, משתמש אחר עלול לקבל אותה. עמודי חשבון, מסמכים ונתוני לקוחות חייבים הגדרות מטמון שלא חושפות מידע בין משתמשים.
דוגמה Vercel/Cloudflare מפיצים assets דרך CDN.
מה לבדוק / איך למנוע בודקים cache, headers, redirects והאם מידע פרטי לא נשמר ב-cache ציבורי. כותרות אבטחה — Security Headers Security Headers
מה זה Headers שהשרת שולח לדפדפן כדי להקשיח התנהגות ולהפחית סיכונים.
למה זה חשוב בדיקה מהירה שנותנת ערך, אבל לא מחליפה הרשאות ו-RLS.
דוגמה CSP, HSTS, Referrer-Policy, Permissions-Policy.
מה לבדוק / איך למנוע בודקים עם SecurityHeaders/Observatory ומחליטים מה רלוונטי לאתר. מדיניות אבטחת תוכן — CSP CSP = Content Security Policy
מה זה Header שמגדיר מאילו מקורות מותר לטעון scripts, styles, images ועוד.
למה זה חשוב יכול לצמצם XSS וטעינת קוד ממקורות לא רצויים.
דוגמה CSP מגביל scripts לדומיין האתר ולשירותים מאושרים.
מה לבדוק / איך למנוע מתחילים בזהירות, בודקים report-only אם צריך, ולא שוברים פונקציונליות. הכרחת HTTPS — HSTS HSTS = HTTP Strict Transport Security
מה זה Header שמורה לדפדפן להשתמש תמיד ב-HTTPS לאתר.
למה זה חשוב מחזק את ההגנה אחרי ש-HTTPS מוגדר תקין.
דוגמה Strict-Transport-Security פעיל בדומיין Production.
מה לבדוק / איך למנוע מפעילים רק אחרי שה-HTTPS עובד יציב בכל הדומיין וה-subdomains הרלוונטיים. מדיניות — Referrer-Policy Referrer-Policy
מה זה Header שמגדיר כמה מידע על העמוד הקודם נשלח לאתרים אחרים.
למה זה חשוב יכול למנוע דליפת URLs פנימיים או פרמטרים רגישים.
דוגמה מעבר מדף פרטי לאתר חיצוני לא צריך לחשוף URL רגיש מלא.
מה לבדוק / איך למנוע מגדירים מדיניות שמאזנת פרטיות וצרכי אנליטיקה. מדיניות הרשאות דפדפן — Permissions-Policy Permissions-Policy
מה זה Header שמגביל שימוש ביכולות דפדפן כמו מצלמה, מיקרופון, מיקום וחיישנים.
למה זה חשוב מקטין הרשאות שאינן נדרשות לאתר.
דוגמה אתר שלא צריך מצלמה חוסם camera/microphone.
מה לבדוק / איך למנוע מגדירים רק יכולות נחוצות ומבטלים את השאר. מניעת הטמעה במסגרת — X-Frame-Options / frame-ancestors X-Frame-Options / CSP frame-ancestors
מה זה מנגנון שמגביל הטמעת האתר בתוך iframe באתרים אחרים.
למה זה חשוב יכול לצמצם סיכוני clickjacking.
דוגמה Admin panel לא אמור להיטען בתוך iframe של אתר אחר.
מה לבדוק / איך למנוע מגדירים frame-ancestors ב-CSP או X-Frame-Options לפי הצורך. הגדרת SameSite לעוגיות — SameSite Cookie SameSite Cookie Attribute
מה זה מאפיין Cookie שמגביל שליחת Cookies בין אתרים.
למה זה חשוב עוזר לצמצם CSRF במערכות מבוססות Cookies.
דוגמה SameSite=Lax או Strict לפי הצורך.
מה לבדוק / איך למנוע בודקים שהגדרת SameSite מתאימה לזרימות login, auth callbacks ושירותים חיצוניים. עוגייה חסומה ל-JavaScript — HttpOnly Cookie HttpOnly Cookie Attribute
מה זה מאפיין שמונע מ-JavaScript בדפדפן לקרוא Cookie.
למה זה חשוב מקטין סיכון אם יש XSS, כי JS לא יכול לקרוא את ה-session cookie.
דוגמה session cookie מסומן HttpOnly.
מה לבדוק / איך למנוע בודקים Cookies רגישים ומעדיפים HttpOnly כשהארכיטקטורה מאפשרת. עוגייה מאובטחת — Secure Cookie Secure Cookie Attribute
מה זה מאפיין שמאפשר שליחת Cookie רק דרך HTTPS.
למה זה חשוב חשוב לכל Cookie רגיש בפרודקשן.
דוגמה session cookie עם Secure=true.
מה לבדוק / איך למנוע בודקים בפרודקשן שכל Cookies רגישים נשלחים רק ב-HTTPS. מדיניות Cache — Cache-Control Cache-Control
מה זה Header שקובע איך דפדפן/CDN שומרים תוכן.
למה זה חשוב Cache לא נכון יכול לשמור מידע פרטי במקום ציבורי או משותף.
דוגמה Dashboard פרטי לא אמור להיות cache ציבורי.
מה לבדוק / איך למנוע מגדירים no-store/private לעמודים פרטיים ו-cache מבוקר ל-assets ציבוריים. ממצא — Finding Security Finding
מה זה בעיה, חולשה, הגדרה חסרה או סיכון שנמצא במהלך בדיקה.
למה זה חשוב הממצא הוא יחידת העבודה בדוח ללקוח.
דוגמה “משתמש רגיל יכול לראות בקשות של משתמש אחר”.
מה לבדוק / איך למנוע לכל ממצא כותבים כותרת, חומרה, מה נמצא, הוכחה, סיכון והמלצת תיקון. הוכחה — Evidence Evidence
מה זה תיעוד שמראה שהממצא אמיתי.
למה זה חשוב הוכחה מצונזרת מאפשרת לוודא שחולשה אמיתית ולבדוק שהתיקון סגר אותה. תיעוד עם סיסמאות או פרטי לקוחות עלול ליצור דליפה נוספת.
דוגמה צילום מסך, URL, תיאור צעדים, Response מצונזר.
מה לבדוק / איך למנוע מתעדים בלי לחשוף מידע רגיש אמיתי; משתמשים בדאטה דמו/מצונזר. תיקון מומלץ — Remediation Remediation
מה זה הפעולה המומלצת כדי לתקן את שורש הבעיה.
למה זה חשוב מבדיל בין “מצאתי בעיה” לבין “יש תוכנית פעולה”.
דוגמה להוסיף RLS policy שמחזירה רק rows של המשתמש המחובר.
מה לבדוק / איך למנוע כותבים תיקון ברור, מעשי, לפי עדיפות, בלי להתחייב לתיקון מלא אם זה מחוץ להיקף. הפחתת סיכון — Mitigation Mitigation
מה זה פעולה שמקטינה סיכון גם אם לא מתקנת את שורש הבעיה לגמרי.
למה זה חשוב שימושי כשאין זמן לתיקון מלא לפני השקה.
דוגמה חסימת עמוד זמנית עד להשלמת תיקון הרשאות.
מה לבדוק / איך למנוע מציינים בדוח אם מדובר במענה זמני ולא תיקון סופי. בדיקה חוזרת — Retest Retest
מה זה בדיקה שנעשית אחרי תיקון כדי לוודא שהבעיה נסגרה.
למה זה חשוב בלי retest אי אפשר לדעת שהתיקון באמת עבד.
דוגמה אחרי תיקון RLS, נכנסים שוב כדניאל ומוודאים שאינו רואה מידע של מאיה.
מה לבדוק / איך למנוע מתעדים סטטוס: פתוח, תוקן, תוקן חלקית, לא ניתן לאימות. היקף בדיקה — Scope (כולל מה מחוץ להיקף) Scope / Out of Scope
מה זה הסכמה כתובה על מה נבדק ומה לא: דומיינים, מסכים, חשבונות, שירותים ועומק הבדיקה.
למה זה חשוב בדיקת האתר הראשי אינה מבטיחה ששירות התשלום או אזור הניהול נבדקו; היקף ברור מונע ביטחון שגוי ובדיקה ללא רשות.
דוגמה נבדקים התחברות, אזור אישי ואחסון מסמכים; בדיקות עומס ומערכת התשלום החיצונית מחוץ להיקף.
מה לבדוק / איך למנוע לפני בדיקה מגדירים אישור, סביבה וגבולות בכתב. בדוח מציינים במפורש מה נבדק, מה לא נבדק ומה דורש בדיקה נפרדת. דיווח אחראי — Responsible Disclosure Responsible Disclosure
מה זה דרך אתית לדווח על חולשה לבעל המערכת בלי לפרסם או לנצל אותה לרעה.
למה זה חשוב חשוב אם תלמיד מוצא בעיה אצל לקוח או צד שלישי.
דוגמה שולחים לבעל האתר תיאור מסודר וממתינים לתגובה במקום לפרסם בפומבי.
מה לבדוק / איך למנוע בודקים רק עם אישור; אם נמצאה בעיה לא צפויה, עוצרים ומדווחים בצורה אחראית. הסכם רמת שירות — SLA SLA = Service Level Agreement
מה זה הגדרת זמני יעד לטיפול או תגובה לפי חומרה.
למה זה חשוב זמני תגובה ותיקון מוסכמים מונעים מחולשה חמורה להישאר פתוחה בלי אחראי. כך יודעים מי מטפל בדליפה או בתקלה ומתי מסלימים אם אין מענה.
דוגמה Critical לטיפול מיידי, High תוך ימים, Medium בהמשך sprint.
מה לבדוק / איך למנוע משתמשים ב-SLA כהמלצה או כחלק מהסכם שירות, לא כהבטחה בלי תיאום. קבלת סיכון — Risk Acceptance Risk Acceptance
מה זה החלטה מודעת של הלקוח לקבל סיכון מסוים במקום לתקן אותו מיד.
למה זה חשוב לא כל ממצא יתוקן מיד, אבל ההחלטה צריכה להיות מודעת ומתועדת.
דוגמה לקוח מחליט לדחות תיקון Low עד לגרסה הבאה.
מה לבדוק / איך למנוע מתעדים מי אישר, מה הסיכון, ולמה נדחה. תקציר מנהלים — Executive Summary Executive Summary
מה זה סיכום קצר בשפה עסקית של מצב האבטחה, הסיכונים והצעדים הבאים.
למה זה חשוב תקציר ברור מאפשר לבעל העסק להבין איזה סיכון עלול לחשוף לקוחות או לעצור פעילות, ומה צריך לתקן קודם. הוא מחבר את ממצאי האבטחה להחלטות ולתקציב.
דוגמה “נמצאה בעיית הרשאות חמורה אחת שמומלץ לתקן לפני השקה”.
מה לבדוק / איך למנוע כותבים קצר, ברור, ללא הפחדות וללא הבטחות “מאובטח 100%”. פרטים טכניים — Technical Details Technical Details
מה זה החלק בדוח שמיועד למפתח/מבצע תיקון ומסביר איך לשחזר ומה לתקן.
למה זה חשוב פרטים מדויקים מאפשרים למפתח לשחזר חולשה, לתקן אותה ולבדוק שלא חזרה. בלי צעדים ותוצאה צפויה, תיקון עלול לטפל רק בסימן החיצוני ולהשאיר את החשיפה.
דוגמה URL, role שנבדק, תוצאה צפויה מול תוצאה בפועל, המלצת תיקון.
מה לבדוק / איך למנוע כוללים מספיק מידע לתיקון, אבל מצנזרים סודות ונתונים אמיתיים. פרוטוקול הקשר למודל — MCP MCP = Model Context Protocol
מה זה פרוטוקול פתוח שמאפשר למודל AI (כמו Claude) להתחבר לכלים, מקורות מידע ושירותים חיצוניים בצורה מתוקננת, במקום אינטגרציה ייעודית לכל כלי.
למה זה חשוב ככל שיותר אתרי Lovable ו-Claude Code מחברים MCP servers (Supabase, GitHub, אימייל ועוד), כל server כזה הוא נקודת גישה נוספת שדורשת בדיקת הרשאות ואמון.
דוגמה Claude Code מתחבר ל-MCP server של Supabase כדי להריץ שאילתות ישירות על בסיס הנתונים של הפרויקט.
מה לבדוק / איך למנוע ממפים אילו MCP servers מחוברים, אילו הרשאות יש לכל אחד, והאם מודל ה-AI יכול לבצע פעולות רגישות בלי אישור מפורש. פיתוח מונחה AI — Vibe Coding Vibe Coding
מה זה שיטת פיתוח שבה המפתח מתאר בשפה טבעית מה הוא רוצה, וכלי AI כמו Lovable, Claude Code או Cursor מייצרים את מרבית הקוד בפועל.
למה זה חשוב כשה-AI כותב את רוב הקוד, קל להחמיץ בדיקות הרשאה, ניהול סודות ו-RLS — בדיוק הפערים שהמילון הזה עוסק בהם.
דוגמה בונה אתר מתאר "מערכת ניהול לקוחות עם התחברות" ל-Lovable, שמייצרת טבלאות, טפסים ו-API תוך דקות.
מה לבדוק / איך למנוע מתייחסים לכל קוד שנוצר על ידי AI כאילו נכתב על ידי מפתח זוטר: קוראים, בודקים הרשאות, ולא מניחים שהוא מאובטח כברירת מחדל. הזיית חבילות AI — Slopsquatting Slopsquatting = AI Package Hallucination Squatting
מה זה מצב שבו מודל AI "ממציא" שם חבילת קוד (npm/PyPI) שלא קיימת באמת, ותוקפים מזהים את הדפוס ונרשמים לשם הזה מראש עם קוד זדוני.
למה זה חשוב כלי Vibe Coding מייצרים import/install commands מהר, ולפעמים בלי שהמפתח בודק שהחבילה אכן קיימת ואמינה.
דוגמה Claude מציע להתקין ספריית "react-secure-forms" שלא קיימת בפועל; תוקף כבר רשם את השם הזה ב-npm עם קוד זדוני.
מה לבדוק / איך למנוע לפני התקנת חבילה שה-AI המליץ עליה, מוודאים שהיא קיימת במאגר הרשמי, עם היסטוריה, downloads ותחזוקה אמיתית. שיוך המוני — Mass Assignment Mass Assignment
מה זה חולשה שבה טופס או API מקבלים אובייקט שלם מהלקוח וכותבים אותו ישירות לטבלה, כולל שדות שהמשתמש לא אמור להיות מסוגל לשנות.
למה זה חשוב נפוץ מאוד באתרי Lovable/Supabase שבהם טופס נקשר ישירות לעמודות ב-DB בלי סינון שדות מפורש.
דוגמה טופס עדכון פרופיל שולח גם role: "admin" בבקשה, וה-API מעדכן את זה כי הוא כותב את כל האובייקט שהתקבל בלי סינון.
מה לבדוק / איך למנוע מוודאים שה-API/Edge Function מעדכן רק רשימת שדות מפורשת ומותרת, ולא שומר את כל מה שהלקוח שלח. 134 Supabase, Lovable ונתונים
התחברות דרך צד שלישי — OAuth 2.0 OAuth 2.0
מה זה פרוטוקול סטנדרטי שמאפשר למשתמש להתחבר לאתר דרך חשבון קיים (Google, GitHub וכו׳) בלי לשתף סיסמה.
למה זה חשוב אתרי Lovable רבים משתמשים ב-Supabase Auth עם OAuth providers, וטעות ב-redirect URLs או scopes יכולה לחשוף מידע או לאפשר התחזות.
דוגמה משתמש לוחץ "התחבר עם Google" ומאשר לאתר גישה לפי ה-scopes שהוגדרו לו מראש.
מה לבדוק / איך למנוע בודקים ש-redirect URLs מוגבלים לדומיינים אמיתיים, וש-scopes המבוקשים הם המינימום הנדרש. AI פועל באופן עצמאי — Agentic AI Agentic AI / AI Agent
מה זה מערכת AI שיכולה לתכנן ולבצע רצף פעולות בעצמה (לא רק לענות על שאלה), כולל קריאה לכלים חיצוניים.
למה זה חשוב ככל שסוכן AI מקבל יותר עצמאות (למשל דרך MCP), כך גדל הצורך לוודא שיש לו רק את ההרשאות המינימליות הנדרשות.
דוגמה Claude Code רץ כ-agent בטרמינל, יכול לקרוא קבצים, להריץ פקודות ולבצע commit בעצמו.
מה לבדוק / איך למנוע בודקים אילו פעולות הסוכן מורשה לבצע ללא אישור אנושי, ומגבילים לפי עיקרון ההרשאה המינימלית. אבטחת סקילים — מקורות מהימנים וכלי בדיקה קריאה לכלים — Tool Use / Function Calling Tool Use / Function Calling
מה זה היכולת של מודל AI לבחור ולהפעיל פונקציה או כלי חיצוני (API, חיפוש, DB) כדי להשלים משימה.
למה זה חשוב כל כלי שמודל AI יכול לקרוא לו הוא בעצם הרשאה — חשוב לדעת אילו כלים חשופים למודל ומה הם מסוגלים לעשות.
דוגמה מודל AI מזהה שצריך לחפש מידע עדכני ובוחר לקרוא לכלי web_search במקום לענות ממידע ישן.
מה לבדוק / איך למנוע רושמים רשימת כלים שחשופים לכל agent/מודל, ומוודאים שאין כלי עם הרשאות רחבות מדי לצורך המשימה. אבטחת סקילים — מקורות מהימנים וכלי בדיקה תקיפת שרשרת אספקה — Supply Chain Attack Supply Chain Attack
מה זה תקיפה שמכוונת לא לאתר עצמו אלא לרכיב שהוא תלוי בו — ספרייה, כלי build, MCP server או שירות חיצוני.
למה זה חשוב אתר יכול להיות כתוב מצוין, אבל עדיין להיפרץ דרך תלות שנפגעה בלי קשר לקוד שלך.
דוגמה עדכון שגרתי של ספריית npm פופולרית מכיל קוד זדוני שמדליף secrets מכל פרויקט שמשתמש בה.
מה לבדוק / איך למנוע עוקבים אחרי Dependabot/advisories, לא מעדכנים dependencies אוטומטית בלי בדיקה, ומגבילים הרשאות ל-CI/CD ול-MCP servers חיצוניים. אבטחת סקילים — מקורות מהימנים וכלי בדיקה חטיפת קליק — Clickjacking Clickjacking
מה זה התקפה שבה אתר זדוני טוען את האתר שלך בתוך iframe שקוף ומטעה משתמש ללחוץ על פעולה בלי לדעת.
למה זה חשוב רלוונטי בעיקר לעמודי ניהול או פעולות רגישות (מחיקה, אישור, תשלום) שיכולות להתבצע בלחיצה אחת.
דוגמה משתמש חושב שהוא לוחץ על כפתור משחק, אבל בפועל הוא לוחץ על כפתור "מחק חשבון" של אתר אחר שטעון מתחתיו בשקיפות.
מה לבדוק / איך למנוע מוודאים שיש frame-ancestors מתאים ב-CSP או X-Frame-Options, במיוחד בעמודי אדמין ופעולות הרסניות. שלמות משאבים — SRI SRI = Subresource Integrity
מה זה מנגנון שמאפשר לדפדפן לוודא שקובץ JS/CSS שנטען מ-CDN חיצוני לא שונה מהגרסה שציפית לה.
למה זה חשוב אם CDN חיצוני נפרץ, SRI מונע מהדפדפן להריץ קוד ששונה בלי ידיעתך.
דוגמה תג script טוען ספריית JS מ-CDN עם attribute integrity שמכיל hash של הקובץ המקורי.
מה לבדוק / איך למנוע לכל script/style שנטען ממקור חיצוני, בודקים אם אפשר וכדאי להוסיף integrity ו-crossorigin. אחזור מועשר בייצור — RAG RAG = Retrieval-Augmented Generation
מה זה טכניקה שבה מודל AI מביא מידע רלוונטי ממקור חיצוני (מסמכים, DB) לפני שהוא מנסח תשובה, במקום להסתמך רק על מה שלמד באימון.
למה זה חשוב שליפת מסמכים בלי בדיקת הרשאות עלולה להעביר למודל מידע פרטי ולחשוף אותו בתשובה למשתמש אחר. ההרשאות חייבות להיבדק לפני שהמסמך מגיע למודל, לא רק אחרי יצירת התשובה.
דוגמה צ׳אטבוט תמיכה שמביא תשובות ממאגר מסמכים פנימי, אבל לא בודק שהמשתמש מורשה לראות את המסמך הספציפי שנשלף.
מה לבדוק / איך למנוע מוודאים שהאחזור (retrieval) מכבד את אותם כללי הרשאה כמו כל שאילתה רגילה למקור המידע. חלון הקשר — Context Window Context Window
מה זה כמות הטקסט (בטוקנים) שמודל AI יכול "לראות" בבת אחת בשיחה או במשימה נתונה.
למה זה חשוב מודל שלא רואה את כל הקבצים וההנחיות הקשורים עלול לפספס בדיקת הרשאות או לשנות קוד באופן שחושף מידע. אין להסתמך על הזיכרון שלו במקום בדיקה של כל החלקים הרגישים.
דוגמה Claude Code מתבקש לתקן קובץ אחד, אבל לא רואה בו-זמנית קובץ הרשאות אחר שתלוי בשינוי הזה.
מה לבדוק / איך למנוע בבקשות משמעותיות, מציינים לסוכן במפורש אילו קבצים/הקשר קשורים, ולא מסתמכים על שהוא "יזכור" הכל. אסימון פעולה — WordPress Nonce WordPress Nonce
מה זה אסימון מוגבל בזמן ובהקשר המסייע לצמצם CSRF; ב-WordPress אינו חד-פעמי באמת.
למה זה חשוב אינו אימות משתמש ואינו הרשאה לפעולה; יש לבדוק capabilities בנפרד.
דוגמה check_admin_referer לצד current_user_can לפני שמירת הגדרות.
מה לבדוק / איך למנוע מאמתים nonce לפעולות משנות מצב ובודקים הרשאה ובעלות גם כשיש nonce תקין. ממשק מרוחק — XML-RPC XML-RPC
מה זה ממשק קריאות מרוחקות עבור שירותים ויישומים של WordPress.
למה זה חשוב ממשק מיותר מגדיל משטח תקיפה; חסימתו עלולה לשבור שירותים תלויים.
דוגמה Jetpack או יישום פרסום מרוחק עשויים להזדקק ל-xmlrpc.php.
מה לבדוק / איך למנוע ממפים שימוש אמיתי, מגבילים קצב ומשביתים רק לאחר בדיקת תלות. תוסף פרוץ — Nulled Plugin Nulled Plugin / Theme
מה זה עותק לא מורשה או ששונה של תוסף או תבנית, לרוב להסרת מגבלות רישוי.
למה זה חשוב עלול לכלול נוזקה או דלת אחורית וללא ערוץ עדכונים מהימן.
דוגמה תוסף בתשלום שהורד מאתר שיתוף במקום מהספק המקורי.
מה לבדוק / איך למנוע בודקים מקור ושלמות, מחליפים בעותק רשמי ובודקים סימני פגיעה אם הותקן עותק חשוד. קובץ תצורה — wp-config.php wp-config.php
מה זה קובץ תצורת WordPress הכולל פרטי מסד נתונים, מפתחות והגדרות מערכת.
למה זה חשוב חשיפתו או חשיפת עותק גיבוי שלו עלולות לחשוף סודות.
דוגמה עותק wp-config.php.bak הנגיש מהדפדפן.
מה לבדוק / איך למנוע מונעים גישה ציבורית, מגבילים בעלות והרשאות ולא משאירים עותקי גיבוי בשורש האתר. הרשאות קבצים — File Permissions WordPress File Permissions
מה זה הרשאות קריאה, כתיבה והרצה לפי בעלים, קבוצה ואחרים.
למה זה חשוב כתיבה ציבורית מאפשרת שינוי קוד; הקשחה לא מתאימה עלולה לשבור שירותים.
דוגמה 755 לתיקיות ו-644 לקבצים הן נקודת התחלה נפוצה, לא כלל אוניברסלי; אין להשתמש ב-777.
מה לבדוק / איך למנוע מתאימים לבעלות ולשרת ומגבילים קובצי סודות בלי לאפשר כתיבה ציבורית. הרשאות פעולה — WordPress Capabilities Roles and Capabilities
מה זה הרשאות מפורטות לפעולות המשויכות לתפקידים ולמשתמשים.
למה זה חשוב משתמש מחובר או nonce תקין אינם הוכחה שמותר לבצע פעולה.
דוגמה current_user_can("edit_post", post_id) לפני עריכת פוסט.
מה לבדוק / איך למנוע בודקים הרשאה לפעולה ולאובייקט; ב-REST מגדירים permission_callback. הגנה וירטואלית — Virtual Patching Virtual Patching
מה זה כללי סינון שמנסים לחסום ניצול חולשה לפני עדכון הקוד.
למה זה חשוב הפחתת סיכון זמנית שאינה מתקנת את התוסף עצמו.
דוגמה כלל WAF חוסם בקשות ניצול עד להתקנת עדכון.
מה לבדוק / איך למנוע מעדכנים כללים, בודקים כיסוי וחסימות שווא ומתקינים תיקון קוד בהקדם. זרימת קלט — Taint Analysis Taint Analysis
מה זה מעקב אחר קלט לא אמין עד לפעולות רגישות כגון SQL, HTML ופקודות shell.
למה זה חשוב קלט מטופס שמגיע לשאילתה או לפקודת שרת עלול לחשוף לקוחות; המעקב עוזר למצוא את המסלול המסוכן לפני פרסום.
דוגמה Psalm יכול לזהות קלט מבקשה המגיע לשאילתת SQL ללא פרמטרים.
מה לבדוק / איך למנוע מפעילים ניתוח taint ובודקים sinks, sanitizers וכיסוי נתיבי קוד. גבול שרת/לקוח — Server Boundary Server / Client Boundary
מה זה הפרדה בין קוד ונתונים המורשים להישאר בשרת לבין מה שנשלח לדפדפן.
למה זה חשוב סוד שנשלח לדפדפן ניתן להעתקה בידי כל מבקר ועלול לאפשר חיובים או גישה למידע בשם העסק.
דוגמה סוד ב-NEXT_PUBLIC או ב-props של רכיב לקוח גלוי למשתמש.
מה לבדוק / איך למנוע בודקים bundles ותגובות API ומאמתים הרשאה בכל Server Action. פענוח אובייקטים לא בטוח — Unsafe Deserialization Unsafe Deserialization
מה זה בניית אובייקטים מקלט חיצוני עלולה לבצע קוד, למשל עם pickle או loaders לא בטוחים.
למה זה חשוב קובץ או הודעה לא אמינים עלולים לגרום להרצת קוד בשרת בעת הפענוח, ולא רק להכנסת נתונים שגויים.
דוגמה pickle.loads על קובץ שהעלה משתמש אינו פורמט נתונים בטוח.
מה לבדוק / איך למנוע מעדיפים JSON וסכמה מוגבלת; נמנעים מפענוח אובייקטים שרירותיים. הגנת נתונים — Data Protection Key Ring ASP.NET Core Data Protection
מה זה מנגנון הגנה על cookies ו-tokens באמצעות מפתחות מנוהלים; אינו תחליף לכל הצפנת נתוני יישום.
למה זה חשוב גניבת המפתחות עלולה לאפשר פענוח או זיוף של מידע מוגן; אובדן שלהם עלול לנתק משתמשים ולבטל קישורים קיימים.
דוגמה כמה מופעי שרת זקוקים ל-key ring משותף ומוגן כדי לקרוא אותה עוגייה.
מה לבדוק / איך למנוע בודקים אחסון מפתחות, הרשאות, הצפנה במנוחה ותחלופה. שרשרת אבטחה — Security Filter Chain Spring SecurityFilterChain
מה זה סדרת מסננים ב-Spring המיישמת אימות והגנות על בקשות בהתאם לנתיב ולתצורה.
למה זה חשוב כלל שמתיר גישה לנתיב רחב מדי עלול לפתוח אזור ניהול גם לאורחים למרות מסך התחברות תקין.
דוגמה permitAll על תבנית רחבה עלול לחשוף endpoint רגיש.
מה לבדוק / איך למנוע בודקים התאמת נתיבים, method security ותרחישים ללא הרשאה. פונקציה בהרשאות הבעלים — SECURITY DEFINER PostgreSQL SECURITY DEFINER
מה זה פונקציה הרצה בהרשאות הבעלים שלה במקום הרשאות הקורא.
למה זה חשוב פונקציה בהרשאות חזקות יכולה לחשוף מידע שהמשתמש אינו רשאי לקרוא אם היא אינה בודקת את זהותו ואת הרשאתו.
דוגמה פונקציה שאינה בודקת את המשתמש עלולה לעקוף מגבלות גישה.
מה לבדוק / איך למנוע מגבילים EXECUTE, מקבעים search_path ובודקים הרשאה לפני פעולות מיוחסות. כללי גישה — Firebase Security Rules Firebase Security Rules
מה זה כללים לאימות בקשות לקוח ל-Firestore, Realtime Database ו-Storage; המוצרים משתמשים בשפות ותצורות שונות.
למה זה חשוב כללים פתוחים ב-Firebase מאפשרים לקרוא או לשנות מידע ישירות, גם כשכפתורים מוסתרים באתר.
דוגמה request.auth.uid חייב להתאים לבעל הרשומה; Admin SDK אינו כפוף לכללים הללו.
מה לבדוק / איך למנוע בודקים rules באמולטור עם בקשות מותרות ואסורות ולא מסתמכים על App Check בלבד. הזרקת NoSQL — NoSQL Injection NoSQL Injection
מה זה שינוי לוגיקת שאילתה באמצעות קלט לא אמין, למשל אופרטור $ne או ביטוי $where במקום ערך רגיל.
למה זה חשוב קלט שמשנה את מסנן החיפוש יכול לעקוף התחברות או להחזיר רשומות של לקוחות אחרים.
דוגמה אובייקט סיסמה המכיל $ne במקום מחרוזת עלול לעקוף בדיקה שנבנתה בצורה לא בטוחה.
מה לבדוק / איך למנוע מאמתים סכמה וסוגים, בונים מסננים משדות מאושרים ולא מעבירים אובייקטי משתמש ישירות לשאילתה. שאילתה מוכנה — Prepared Statement Prepared Statement / Parameterized Query
מה זה הפרדת תבנית SQL מהערכים באמצעות פרמטרים, כך שקלט נתפס כנתון ולא כקוד SQL.
למה זה חשוב הפרדת הקלט מהשאילתה מונעת ממשתמש להפוך שדה בטופס להוראה לקרוא או למחוק מידע.
דוגמה משתמשים ב-WHERE email = ? וב-binding במקום לשרשר את כתובת הדוא״ל.
מה לבדוק / איך למנוע בודקים שאין שרשור קלט ב-raw SQL; שמות טבלאות ועמודות נבחרים מתוך רשימה מאושרת. משתמש מסד בהרשאות מינימליות — Least-Privilege DB User Least-Privilege Database User
מה זה חשבון ייעודי ליישום עם הפעולות והמסדים הנדרשים בלבד, ללא הרשאות ניהול או שינוי הרשאות.
למה זה חשוב אם האתר נפרץ, חשבון מסד מוגבל מצמצם מחיקה וחשיפה; חשבון מנהל עלול לתת לתוקף שליטה במסדים נוספים.
דוגמה היישום אינו מתחבר כ-sa, root או db_owner; חשבון migrations נפרד מחשבון זמן הריצה.
מה לבדוק / איך למנוע סוקרים grants ותפקידים, ובודקים שפעולות מחוץ לצורכי היישום נדחות. הצפנה שקופה — TDE Transparent Data Encryption
מה זה הצפנת קובצי מסד הנתונים במנוחה; אינה מונעת ממשתמש מורשה לבצע SELECT ואינה מחליפה TLS.
למה זה חשוב הצפנה מגנה על קובצי מסד שנגנבו, אך אובדן מפתחות יכול להפוך גיבוי לבלתי ניתן לשחזור.
דוגמה SQL Server מצפין קובצי נתונים ולוג באמצעות מפתח המוגן בתעודה או במערכת ניהול מפתחות.
מה לבדוק / איך למנוע בודקים מצב הצפנה, מגבים ומגנים על המפתחות והתעודות ומתרגלים שחזור. מיסוך נתונים — Data Masking Dynamic Data Masking
מה זה הצגת ערך מוסתר למשתמשים מוגבלים בלי לשנות את המידע המאוחסן; אינו הצפנה או גבול אבטחה בפני עצמו.
למה זה חשוב ערך שמוסתר במסך עדיין קיים במסד; הסתמכות על מיסוך במקום הרשאות עלולה לחשוף מידע אישי.
דוגמה מספר כרטיס מוצג עם ארבע ספרות אחרונות, אך הרשאות UNMASK או שאילתות מסוימות עשויות לחשוף מידע.
מה לבדוק / איך למנוע משלבים הרשאות מינימליות, בודקים UNMASK וניסיונות הסקת מידע, ולא מסתמכים על מיסוך בלבד. אימות דו-שלבי — 2FA/MFA Two-Factor / Multi-Factor Authentication
מה זה התחברות באמצעות שני סוגי הוכחה לפחות, למשל סיסמה וקוד מאפליקציית אימות. שני שדות סיסמה אינם שני גורמים.
למה זה חשוב סיסמה שנגנבה לבדה לא מספיקה לכניסה לחשבון מנהל; קוד במסרון פחות עמיד לדיוג ממפתח אבטחה.
דוגמה מנהל מזין סיסמה ומאשר באמצעות אפליקציית אימות.
מה לבדוק / איך למנוע מפעילים לכל המנהלים, שומרים קודי שחזור במקום מוגן ובודקים שתהליך שחזור לא עוקף את ההגנה. מפתחות גישה — Passkeys Passkeys / WebAuthn
מה זה התחברות באמצעות מפתח הצפנה במכשיר או במפתח אבטחה, שנפתחת לרוב בטביעת אצבע, פנים או קוד מכשיר. המפתח קשור לאתר המסוים.
למה זה חשוב אין סיסמה לשימוש חוזר, והקישור לדומיין מקשה על אתר מתחזה לגנוב את פרטי ההתחברות.
דוגמה בעל העסק נכנס לניהול עם טביעת אצבע במקום סיסמה.
מה לבדוק / איך למנוע משתמשים בספק התחברות שתומך ב-Passkeys, בודקים מכשיר נוסף ושחזור חשבון ומגנים גם על אמצעי הכניסה החלופיים. גיבוב סיסמאות — Password Hashing Password Hashing / bcrypt / Argon2id
מה זה שמירת תוצאה חד-כיוונית של הסיסמה במקום הסיסמה עצמה, באמצעות מנגנון ייעודי כמו Argon2id או bcrypt ומלח אקראי לכל סיסמה.
למה זה חשוב אם מסד הנתונים נחשף, גיבוב ייעודי מקשה על שחזור סיסמאות לקוחות; הצפנה הפיכה או SHA-256 לבדו אינם פתרון מתאים.
דוגמה ספק ההתחברות שומר גיבוב ומשווה אליו בעת כניסה, בלי לשמור את הסיסמה המקורית.
מה לבדוק / איך למנוע מעדיפים ספק התחברות מוכר; אם מנהלים סיסמאות בעצמכם משתמשים בספרייה מתוחזקת ובהגדרות עדכניות, ולא כותבים מנגנון לבד. מפתח API — API Key API Key
מה זה מזהה שנותן לאפליקציה גישה לשירות. יש מפתחות ציבוריים שנועדו לדפדפן ומפתחות סודיים שמאפשרים פעולות או חיוב.
למה זה חשוב מפתח סודי שנחשף באתר מאפשר לאחרים לצרוך שירות בתשלום או לגשת לנתוני העסק.
דוגמה מפתח לשירות AI נשמר בשרת; מפתח ציבורי מוגבל אינו מחליף הרשאות לנתונים.
מה לבדוק / איך למנוע מסווגים כל מפתח לפי תיעוד הספק, מגבילים הרשאות והוצאות, ולא שולחים סודות לדפדפן או לצ׳אט. החלפת מפתחות — Key Rotation Key Rotation
מה זה הנפקת מפתח חדש, העברת השירותים אליו וביטול הישן לפי תהליך מתוכנן או בעקבות חשיפה.
למה זה חשוב מחיקת מפתח מהקוד אינה מבטלת עותק שכבר נגנב; ביטול אצל הספק הוא מה שסוגר את הגישה.
דוגמה אחרי חשיפת מפתח דואר מחליפים אותו בשירות ובאתר ובודקים שלא נשלחו הודעות זרות.
מה לבדוק / איך למנוע מכינים רשימת שירותים המשתמשים במפתח, בודקים את החדש ומבטלים את הישן; בחשיפה פעילה מבטלים במהירות ובודקים פעילות חריגה. קישור קסם — Magic Link Magic Link
מה זה קישור מוגבל בזמן הנשלח לאימייל ומאפשר להתחבר בלי להקליד סיסמה.
למה זה חשוב מי שמחזיק בקישור עשוי להיכנס לחשבון; תיבת דואר שנפרצה או קישור שנרשם בלוג עלולים לאפשר השתלטות.
דוגמה לקוח מקבל קישור כניסה חד-פעמי לאזור האישי.
מה לבדוק / איך למנוע בודקים תפוגה ושימוש חד-פעמי, מגבילים שליחות, מונעים רישום קישורים בלוג ומאשרים רק כתובות חזרה מוכרות. כתובות הפניה מאושרות — Redirect URL Allowlist Redirect URL Allowlist
מה זה רשימת כתובות שאליהן מותר לשירות ההתחברות להחזיר את המשתמש אחרי כניסה או איפוס סיסמה.
למה זה חשוב כתובת חזרה רחבה או בשליטת זר עלולה לשלוח משתמש או פרטי כניסה לאתר מתחזה.
דוגמה החזרה מ-Google מותרת רק לעמוד הכניסה המאושר בדומיין העסק.
מה לבדוק / איך למנוע מגדירים כתובות HTTPS מדויקות ככל האפשר, מפרידים בדיקה מאתר חי ומוודאים שכתובת זרה ותחילית דומה נדחות. אישור אימייל — Email Verification Email Verification
מה זה הוכחה שהמשתמש יכול לקבל הודעה בכתובת שמסר, באמצעות קישור או קוד מוגבל בזמן. אינה הוכחת זהות משפטית.
למה זה חשוב בלי אישור אפשר להירשם בשם כתובת של לקוח אחר; אישור לבדו אינו מונע חשבונות זדוניים.
דוגמה משתמש מאשר את כתובתו לפני שימוש באזור האישי.
מה לבדוק / איך למנוע בודקים שחשבון לא מאושר אינו מקבל יכולות רגישות, שקודים פוקעים ושגם החלפת כתובת דורשת אישור מחדש. גניבת סשן — Session Hijacking Session Hijacking
מה זה שימוש בעוגייה או בטוקן התחברות שנגנבו כדי לפעול בשם משתמש שכבר התחבר.
למה זה חשוב תוקף עם סשן תקף עשוי לעקוף את שלב הסיסמה וגם את האימות הדו-שלבי.
דוגמה עוגיית מנהל דולפת ללוג ותוקף משתמש בה כדי לפתוח את הניהול.
מה לבדוק / איך למנוע מונעים XSS ודליפת טוקנים, משתמשים ב-HTTPS ובעוגיות מוגנות כשמתאים, ובודקים ביטול סשנים אחרי יציאה ואירוע חשוד. מילוי אישורים — Credential Stuffing Credential Stuffing
מה זה ניסיונות התחברות עם צמדי אימייל וסיסמה שדלפו משירותים אחרים, בניגוד לניחוש סיסמאות חדשות.
למה זה חשוב לקוחות שממחזרים סיסמאות עלולים לאבד את החשבון אצלכם גם בלי שהאתר שלכם נפרץ קודם.
דוגמה בוט מנסה אלפי פרטי כניסה מדליפה חיצונית באזור הלקוחות.
מה לבדוק / איך למנוע מגבילים ניסיונות לפי חשבון ומקור, מפעילים MFA או Passkeys, מזהים חריגות ומוסיפים הגנת בוטים בלי לנעול לקוחות בקלות. התחברות אחודה — SSO SSO = Single Sign-On
מה זה כניסה לכמה שירותים באמצעות ספק זהות אחד, עם מנגנונים כמו OpenID Connect או SAML.
למה זה חשוב אפשר לבטל גישה לעובד שעזב במקום אחד; טעות בחיבור או חשבון זהות שנפרץ עלולים להשפיע על כמה מערכות.
דוגמה עובדי העסק נכנסים למערכת עם החשבון הארגוני.
מה לבדוק / איך למנוע מגבילים לארגון המאושר, בודקים תפקידים וביטול גישה, מפעילים MFA אצל ספק הזהות ומגנים על חשבון חירום. הפניה פתוחה — Open Redirect Open Redirect
מה זה האתר מפנה לכתובת שהמשתמש סיפק בלי לוודא שהיא יעד מותר.
למה זה חשוב תוקף יכול להפיץ קישור שנראה שייך לעסק אך שולח את הלקוח לאתר דיוג, ובזרימות כניסה גם לסכן פרטים רגישים.
דוגמה קישור כניסה מקבל next עם כתובת זרה ומפנה אליה לאחר ההתחברות.
מה לבדוק / איך למנוע מעדיפים נתיבים פנימיים מאושרים, בודקים את הכתובת לאחר פענוח ודוחים יעדים זרים, כולל כתובות שמתחילות ב-//. מעבר נתיבים — Path Traversal Path Traversal
מה זה שימוש בקלט שמשנה נתיב קובץ כדי להגיע לקבצים מחוץ לתיקייה המותרת.
למה זה חשוב מסך הורדת מסמכים עלול לחשוף קובצי תצורה, סודות או קבצים של לקוחות אחרים.
דוגמה שם קובץ שנשלח להורדה גורם לשרת לחפש מחוץ לתיקיית המסמכים.
מה לבדוק / איך למנוע לא מקבלים נתיב חופשי מהלקוח; משתמשים במזהה קובץ, בודקים בעלות ובודקים שהנתיב הסופי נשאר בתיקייה המותרת. העלאת קבצים לא בטוחה — Unrestricted File Upload Unrestricted File Upload
מה זה קבלת קבצים ללא הגבלת סוג, גודל, הרשאה או אופן האחסון וההצגה.
למה זה חשוב קובץ זדוני עלול לרוץ בשרת, לפגוע במי שפותח אותו או למלא את האחסון וליצור חיובים.
דוגמה טופס שמיועד לתמונות מקבל גם קובץ הרצה או מסמך ענק.
מה לבדוק / איך למנוע מאמתים סוג ותוכן בשרת, מגבילים גודל וקצב, מייצרים שם חדש, שומרים בלי יכולת הרצה ובודקים הרשאות וסריקת נוזקות לפי הצורך. השתלטות על תת-דומיין — Subdomain Takeover Subdomain Takeover
מה זה מצב שבו תת-דומיין עדיין מפנה לשירות חיצוני שבוטל, ואחר יכול לתפוס את היעד ולהציג תוכן תחת כתובת העסק.
למה זה חשוב כתובת אמינה של העסק יכולה לשמש להתחזות ולפגיעה בלקוחות אף שהאתר הראשי תקין.
דוגמה עמוד קמפיין ישן מפנה לאחסון שנמחק אצל ספק חיצוני.
מה לבדוק / איך למנוע ממפים תתי-דומיין ורשומות DNS, מסירים הפניות לפני ביטול שירותים ומנטרים יעדים לא פעילים; בודקים רק נכסים שבבעלותכם. חסימת בוטים — CAPTCHA / Bot Protection CAPTCHA / Bot Protection
מה זה בדיקות וכללי סינון שמקשים על שליחה אוטומטית של טפסים ועל שימוש לרעה; אינם הוכחה מוחלטת לאדם.
למה זה חשוב בוטים יכולים להציף לידים מזויפים, בקשות כניסה ופעולות בתשלום ולהפריע ללקוחות אמיתיים.
דוגמה בדיקת בוט מוצגת אחרי פעילות חשודה בטופס יצירת קשר.
מה לבדוק / איך למנוע מאמתים את תוצאת הבדיקה בשרת, בודקים תוקף והקשר, משלבים הגבלת קצב ודואגים לנגישות ולחלופה ללקוחות שנחסמו. מלכודת דבש בטופס — Honeypot Field Honeypot Field
מה זה שדה נסתר ממשתמש רגיל שבוטים פשוטים נוטים למלא; מילוי שלו מסמן חשד לספאם.
למה זה חשוב יכול לצמצם ספאם בלי להטריד לקוחות, אך בוטים מתקדמים עוקפים אותו ומילוי אוטומטי עלול ליצור חסימות שווא.
דוגמה טופס פנייה כולל שדה שלא אמור להישלח עם ערך.
מה לבדוק / איך למנוע בודקים בשרת, מוציאים אותו מניווט מקלדת וקוראי מסך, ובודקים מנהלי סיסמאות; לא משתמשים בו כהגנה יחידה. מניעת שירות — DDoS DDoS = Distributed Denial of Service
מה זה הצפת האתר או שירותיו ממקורות רבים כדי להאט או להשבית אותם.
למה זה חשוב גם בלי גניבת נתונים העסק עלול להפסיד מכירות, פניות וזמינות בזמן ההצפה.
דוגמה אלפי בקשות ממכשירים שונים מעמיסות על החיפוש באתר.
מה לבדוק / איך למנוע מפעילים הגנה אצל ספק התשתית, מגבילים פעולות יקרות, מנטרים זמינות ומכינים נוהל חירום; לא מבצעים בדיקת עומס ללא תיאום. ארנק מתרוקן — Denial of Wallet / Spending Limit Denial of Wallet / Spending Limit
מה זה שימוש לרעה בפעולות שמחויבות לפי צריכה, כמו AI, מסרונים ואחסון, כדי לייצר חשבון גדול גם בלי להשבית את האתר.
למה זה חשוב טופס AI ציבורי ללא מכסה יכול לצבור חיובים שהעסק לא תכנן; התראת תקציב אינה בהכרח עצירת חיוב.
דוגמה בוט מבקש שוב ושוב יצירת תמונות דרך מפתח השירות של העסק.
מה לבדוק / איך למנוע אוכפים מכסות בשרת לפי משתמש ופעולה, מגבילים גודל ומשך, מגדירים עצירת צריכה אם הספק תומך ובודקים בפועל מה קורה כשהמכסה נגמרת. אימות דומיין לדואר — SPF / DKIM / DMARC Sender Policy Framework / DomainKeys Identified Mail / Domain-based Message Authentication, Reporting and Conformance
מה זה SPF מציין שרתים מורשים לשליחה, DKIM חותם הודעות ו-DMARC קובע מדיניות ודיווח לפי התאמה לדומיין השולח.
למה זה חשוב הגדרה תקינה מצמצמת התחזות לדומיין העסק ומשפרת אמינות דואר, אך אינה חוסמת שמות שולח או דומיינים דומים מזויפים.
דוגמה העסק מאשר גם את ספק הדואר וגם את שירות החשבוניות לפני מדיניות דחייה.
מה לבדוק / איך למנוע ממפים שולחים, בודקים רשומות וחתימות ומתחילים בדוחות DMARC; עוברים להסגר או דחייה אחרי אימות כדי לא לחסום דואר עסקי אמיתי. התחזות בדוא״ל — Phishing / Email Spoofing Phishing / Email Spoofing
מה זה הודעה שמתחזה לגורם אמין כדי לגנוב פרטי כניסה, כסף או מידע. זיוף שולח הוא אחת הדרכים, אך דיוג יכול להגיע גם מחשבון אמיתי שנפרץ.
למה זה חשוב בקשת תשלום או איפוס מזויפת יכולה לפגוע בעסק גם כשהאתר עצמו מאובטח.
דוגמה הודעה מתחזה לספק ומבקשת לשנות חשבון בנק לתשלום.
מה לבדוק / איך למנוע מאמתים בקשות רגישות בערוץ מוכר נוסף, בודקים דומיין מלא, מפעילים MFA והגנות דואר ומאפשרים לעובדים לדווח בלי לחשוש. הצפנה בתעבורה ובמנוחה — Encryption in Transit / at Rest Encryption in Transit / Encryption at Rest
מה זה הצפנה בתעבורה מגנה על המידע בדרך, למשל עם TLS; הצפנה במנוחה מגנה על קבצים, מסדים וגיבויים כשהם מאוחסנים.
למה זה חשוב HTTPS אינו מגן על גיבוי שנגנב, והצפנת מסד אינה מונעת ממשתמש מורשה לקרוא נתונים; צריך את שתיהן לצד הרשאות.
דוגמה טופס לקוחות נשלח ב-HTTPS והמסד והגיבויים מוצפנים אצל ספק האחסון.
מה לבדוק / איך למנוע בודקים TLS גם בין השרת למסד, אימות תעודות והצפנת גיבויים; מגנים על המפתחות ומתרגלים שחזור. חולשת יום אפס — Zero-Day Zero-Day Vulnerability
מה זה חולשה שטרם הייתה ידועה לספק או שאין עבורה תיקון זמין; אם משתמשים בה לתקיפה, זהו ניצול יום אפס.
למה זה חשוב אתר מעודכן עדיין עלול להיות חשוף לחולשה חדשה, ולכן עדכונים לבדם אינם מחליפים הרשאות מוגבלות וניטור.
דוגמה מתגלה ניצול של חולשה בתוסף לפני שהספק מפרסם תיקון.
מה לבדוק / איך למנוע עוקבים אחרי הודעות ספקים, מצמצמים חשיפה ומשביתים זמנית יכולת מסוכנת לפי הצורך; מתקינים תיקון לאחר שפורסם ונבדק. עדכון אבטחה — Security Patch Security Patch
מה זה עדכון שמתקן חולשת אבטחה במוצר, תוסף או חבילת קוד.
למה זה חשוב גרסה פגיעה נשארת חשופה גם אם האתר נראה תקין; דחיית תיקון פעיל מאריכה את חלון הסיכון.
דוגמה ספק תוסף מפרסם גרסה שסוגרת העלאת קבצים ללא הרשאה.
מה לבדוק / איך למנוע בודקים גרסאות מושפעות ומתוקנות, מגבים ובודקים תאימות, מתקינים בזמן לפי הסיכון ומוודאים שהגרסה החדשה באמת פעילה. נוזקה ודלת אחורית — Malware / Backdoor Malware / Backdoor
מה זה נוזקה היא תוכנה שפוגעת או גונבת; דלת אחורית היא דרך גישה נסתרת שעוקפת את מנגנון ההתחברות הרגיל.
למה זה חשוב תוסף נגוע יכול לגנוב נתוני לקוחות ולהחזיר תוקף לאתר גם אחרי החלפת סיסמה.
דוגמה תבנית לא רשמית מוסיפה חשבון מנהל נסתר וקוד שמוציא מידע.
מה לבדוק / איך למנוע מתקינים ממקור רשמי, בודקים קבצים וחשבונות חריגים; במקרה חשד מבודדים, שומרים ראיות ובודקים ניקוי ושורש הפגיעה לפני שחזור. כופרה — Ransomware Ransomware
מה זה נוזקה או פעילות תקיפה שחוסמות גישה למידע, לרוב באמצעות הצפנה, ולעיתים גם גונבות מידע ומאיימות לפרסם אותו.
למה זה חשוב העסק עלול לאבד שירות ונתונים; גיבוי שמחובר לאותן הרשאות עלול להימחק יחד עם המקור.
דוגמה קובצי האתר והגיבוי הנגיש לשרת מוצפנים ונדרשת תמורה לשחרורם.
מה לבדוק / איך למנוע שומרים גיבוי מבודד וגרסאות, מתרגלים שחזור ומגבילים הרשאות; בעת אירוע מבודדים ופונים למומחה, בלי להניח שתשלום מבטיח שחזור. סמכויות יתר לסוכן — Excessive Agency Excessive Agency
מה זה סוכן AI מקבל יותר כלים, הרשאות או עצמאות ממה שנחוץ למשימה.
למה זה חשוב הוראה זדונית במסמך או טעות של המודל עלולות להפוך תשובה שגויה למחיקה, תשלום או חשיפת לקוחות.
דוגמה סוכן שמסכם פניות יכול גם למחוק את כל הפניות ללא אישור.
מה לבדוק / איך למנוע נותנים כלים והרשאות מינימליים, בודקים הרשאה בשרת ודרושים אישור אנושי לפני פעולות רגישות; פרומפט בלבד אינו גבול אבטחה. אבטחת סקילים — מקורות מהימנים וכלי בדיקה דליפת פרומפט מערכת — System Prompt Leakage System Prompt Leakage
מה זה חשיפת הוראות פנימיות שניתנו למודל, דרך תשובותיו או דרך מידע שהמערכת מציגה.
למה זה חשוב ההוראות עשויות לחשוף כללים פנימיים; אם שמתם בהן סודות או הסתמכתם עליהן להרשאות, החשיפה מסוכנת במיוחד.
דוגמה צ׳אט מציג את הוראות הטיפול בלקוחות במקום תשובה ללקוח.
מה לבדוק / איך למנוע לא מכניסים סודות לפרומפט, אוכפים הרשאות מחוץ למודל ובודקים בתרחישי בדיקה שאין חשיפת מידע פנימי רגיש. פריצת מגבלות מודל — Jailbreak LLM Jailbreak
מה זה ניסיון לגרום למודל לעקוף מגבלות התנהגות או בטיחות באמצעות ניסוח קלט מטעה.
למה זה חשוב מודל שחורג מהמגבלות עלול ליצור תוכן מזיק; אם הוא מחובר לכלים, הנזק יכול לעבור מתוכן לפעולות באתר.
דוגמה משתמש מנסה לשכנע צ׳אט תמיכה לבצע פעולה שאינה מותרת לו.
מה לבדוק / איך למנוע בודקים עמידות בסביבה מורשית, מגבילים כלים והרשאות ומאמתים פלט ופעולות; אין להסתמך על סירוב המודל כהגנה יחידה. אבטחת סקילים — מקורות מהימנים וכלי בדיקה דליפת מידע רגיש דרך המודל — Sensitive Information Disclosure (LLM) Sensitive Information Disclosure (LLM)
מה זה תשובת AI שחושפת מידע אישי, סודות או מסמכים שהמשתמש אינו רשאי לראות, למשל מתוך נתונים שנשלחו למודל.
למה זה חשוב צ׳אט שנראה תמים יכול לחשוף מידע של לקוח אחר אם המקורות שנשלפו לא סוננו לפי הרשאות.
דוגמה צ׳אט שירות מצטט חוזה של לקוח אחר מתוך מאגר מסמכים משותף.
מה לבדוק / איך למנוע מסננים מקורות לפי המשתמש לפני שליחה למודל, מצמצמים מידע אישי, בודקים תנאי שמירה אצל הספק ומנסים שני חשבונות בדיקה נפרדים. אבטחת סקילים — מקורות מהימנים וכלי בדיקה עשרת סיכוני האבטחה למודלים — OWASP Top 10 for LLM OWASP Top 10 for Large Language Model Applications
מה זה רשימת סיכונים של OWASP ליישומים עם מודלי שפה, כמו הזרקת פרומפט, דליפת מידע וסמכויות יתר לסוכן. אינה תעודת אבטחה.
למה זה חשוב צ׳אט וסוכן מוסיפים סיכונים שבדיקת אתר רגילה עשויה לפספס, במיוחד כשהם קוראים מסמכים או מפעילים שירותים בתשלום.
דוגמה בסקירת צ׳אט עסקי בודקים הרשאות למקורות, טיפול בפלט ומכסת שימוש לצד ההנחיות למודל.
מה לבדוק / איך למנוע בודקים את המהדורה הרשמית העדכנית בפרויקט OWASP GenAI, ממפים את הסיכונים לחיבורים שלכם ומוסיפים בדיקות לכל סיכון רלוונטי. אבטחת סקילים — מקורות מהימנים וכלי בדיקה 194 Supabase, Lovable ונתונים
יועץ אבטחה למסד — Supabase Security Advisor Supabase Security Advisor
מה זה כלי שמתריע על הגדרות מסד מסוכנות כגון טבלאות חשופות, RLS חסר ופונקציות שדורשות הקשחה.
למה זה חשוב טבלה שה-AI יצר יכולה להישאר חשופה בלי סימן במסך; התראה עוזרת לזהות זאת לפני שנאספים לקוחות אמיתיים.
דוגמה הכלי מזהה טבלה ללא RLS שמכילה פניות לקוחות.
מה לבדוק / איך למנוע קוראים כל התראה, בודקים את ההקשר ומתקנים, ואז מאמתים בפועל כאורח וכמשתמש אחר; הכלי אינו מבין את כל חוקי העסק. סורק האבטחה של Lovable — Lovable Security Scan Lovable Security Scan
מה זה בדיקת אבטחה בפרויקט Lovable שמסייעת לזהות סיכונים בקוד ובהגדרות לפני פרסום. הכיסוי תלוי בפרויקט וביכולות הזמינות.
למה זה חשוב קוד שנוצר במהירות יכול לכלול סוד גלוי או הרשאה רחבה; סריקה נותנת התרעה אך אינה מבטיחה שהאתר בטוח.
דוגמה לפני פרסום בעל האתר בודק ממצאים על גישה למידע ומפתח שנחשף.
מה לבדוק / איך למנוע מריצים לפני פרסום ואחרי שינוי רגיש, מאמתים ומתקנים ממצאים ומשלימים בדיקה ידנית עם שני משתמשים ובמצב אורח. 196 Supabase, Lovable ונתונים
אימות מקור האפליקציה — Firebase App Check Firebase App Check
מה זה מנגנון שמשתמש באימות מקור כדי לצמצם בקשות מלקוחות לא מוכרים לשירותי Firebase נתמכים. אינו זיהוי משתמש.
למה זה חשוב יכול להפחית שימוש לרעה בשירותים ובחיוב, אבל אינו מונע ממשתמש באפליקציה לגשת לנתונים בלי כללי הרשאה תקינים.
דוגמה האפליקציה שולחת אסימון App Check לצד בקשה ל-Firestore.
מה לבדוק / איך למנוע בודקים תמיכה בשירותים, מנטרים לפני אכיפה, מסירים אסימוני debug מאתר חי ומשלבים Auth, Security Rules ומכסות. 197 פרטיות, גיבוי ותגובה לאירוע
מידע אישי מזהה — PII PII = Personally Identifiable Information
מה זה מידע שמזהה אדם ישירות או בשילוב נתונים אחרים, למשל אימייל, טלפון או פרטי הזמנה המקושרים ללקוח.
למה זה חשוב טופס פשוט יכול לאסוף מידע שדליפתו פוגעת בלקוחות; גם לוג או מידע שנשלח ל-AI עשויים להכיל פרטים מזהים.
דוגמה שם, טלפון ותוכן פנייה נשמרים יחד בטבלת לידים.
מה לבדוק / איך למנוע ממפים מה נאסף ולמי נשלח, מצמצמים שדות ותקופת שמירה, מגבילים גישה ומשתמשים בנתונים מומצאים לבדיקות. 198 פרטיות, גיבוי ותגובה לאירוע
רגולציית פרטיות — חוק הגנת הפרטיות / GDPR Israel Privacy Protection Law and Data Security Regulations / General Data Protection Regulation
מה זה בישראל חוק הגנת הפרטיות ותקנות הגנת הפרטיות (אבטחת מידע) מסדירים היבטים של טיפול במידע אישי. GDPR היא רגולציה אירופית, שעשויה לחול גם על עסק מחוץ לאירופה בתנאים מסוימים.
למה זה חשוב איסוף פרטי לקוחות יוצר אחריות למידע; חובות אבטחה, שקיפות ודיווח תלויות בפעילות, במידע ובדין החל ולא רק במיקום השרת.
דוגמה עסק ישראלי שמציע שירות לאנשים באיחוד האירופי צריך לבדוק גם אם GDPR חלה עליו.
מה לבדוק / איך למנוע ממפים מידע, מטרות, ספקים וקהלי יעד, קוראים מקורות רשמיים ופונים לייעוץ מוסמך לקביעת החובות. זהו הסבר כללי, לא ייעוץ משפטי. 199 פרטיות, גיבוי ותגובה לאירוע
דליפת מידע — Data Breach Data Breach
מה זה אירוע שבו מידע נחשף או נגיש ללא הרשאה; בהקשר פרטיות אירוע יכול לכלול גם אובדן, שינוי או השמדה לא מורשים של מידע אישי.
למה זה חשוב גם קישור ציבורי בטעות למסמך לקוח הוא אירוע שדורש בירור; היעדר הוכחת הורדה אינו הוכחה שלא הייתה חשיפה.
דוגמה אזור מסמכים הוגדר ציבורי וחשבוניות לקוחות נפתחו ללא התחברות.
מה לבדוק / איך למנוע סוגרים את החשיפה, שומרים תיעוד, בודקים איזה מידע ולכמה זמן נחשף ומפעילים נוהל תגובה; בוחנים חובות דיווח עם גורם מוסמך. 200 פרטיות, גיבוי ותגובה לאירוע
תגובה לאירוע — Incident Response Incident Response
מה זה תהליך לזיהוי אירוע אבטחה, עצירת הפגיעה, בירור, התאוששות ולמידה כדי שלא יחזור.
למה זה חשוב פעולה לחוצה כמו מחיקת השרת יכולה לאבד ראיות; נוהל ואיש קשר מראש מקצרים השבתה ומונעים נזק נוסף.
דוגמה לאחר חשיפת מפתח עוצרים שימוש, מחליפים אותו, בודקים פעילות ומוודאים שהשירות חוזר בבטחה.
מה לבדוק / איך למנוע מגדירים אחראי וערוץ חירום, מתרגלים תרחיש, שומרים לוגים מוגנים ומכינים דרך לביטול סשנים ומפתחות ולשחזור נקי. 201 פרטיות, גיבוי ותגובה לאירוע
גיבוי ושחזור — Backup & Restore Backup & Restore / PITR = Point-in-Time Recovery
מה זה גיבוי הוא עותק שניתן לשחזר ממנו. PITR מאפשר, במערכות שתומכות בכך, חזרה לנקודת זמן בתוך חלון השמירה באמצעות גיבויים ויומן שינויים.
למה זה חשוב כפתור גיבוי אינו מבטיח התאוששות: ייתכן שקבצים חסרים, שהעותק נגוע או שהמפתחות אבדו.
דוגמה אחרי מחיקה שגויה משחזרים מסד לזמן שלפני המחיקה ומחזירים קובצי לקוחות מגיבוי נפרד.
מה לבדוק / איך למנוע בודקים כיסוי מסד וקבצים, בידוד והצפנה, חלון PITR ומפתחות; מתרגלים שחזור בסביבה נפרדת ובודקים נתונים, הרשאות וזמן חזרה. 202 פרטיות, גיבוי ותגובה לאירוע
נקודת שחזור — RPO/RTO Recovery Point Objective / Recovery Time Objective
מה זה RPO הוא יעד לכמות המידע שמוכנים לאבד, במונחי זמן. RTO הוא יעד למשך הזמן עד שהשירות חוזר לעבוד; שניהם יעדים ולא הבטחה.
למה זה חשוב גיבוי יומי עלול לאבד יום הזמנות, ושחזור שאורך יומיים לא מתאים לעסק שצריך לחזור תוך שעה.
דוגמה העסק מגדיר יעד לאובדן של עד שעה של נתונים ולחזרה בתוך ארבע שעות.
מה לבדוק / איך למנוע מחליטים לפי צורכי העסק, מתאימים תדירות גיבוי ויכולת שחזור, ומודדים בתרגיל אם היעדים באמת ניתנים להשגה. 
