$ cat /glossary

מילון מושגים מקצועי לאבטחת Lovable ו-AI

141 מונחים מרכזיים לבוני אתרי Vibe Coding, Lovable ו-Claude Code — מ-OWASP ו-RLS ועד דוחות ללקוח. עם חיפוש חופשי, סינון לפי קטגוריה ומיון.

$ מציג 141 מתוך 141 מונחים

1מושגי יסוד

משטח תקיפה — Attack Surface

Attack Surface

מה זה: כל המקומות שדרכם משתמש, שירות חיצוני או תוקף פוטנציאלי יכולים לתקשר עם המערכת או להשפיע עליה.
למה זה חשוב: באתרי Lovable/AI המשטח גדל מהר: טפסים, Login, Supabase, קבצים, דומיין, API ו-Webhooks יכולים להיווצר בלי שבונה האתר שם לב.
דוגמה: פורטל עם טופס, אזור אישי, מסמכים ו-Admin Panel כולל יותר נקודות בדיקה מדף נחיתה פשוט.
מה לבדוק / איך למנוע: ממפים את כל הכניסות למערכת: עמודים, טפסים, API, Storage, משתמשים, Roles וחיבורים חיצוניים.

2מושגי יסוד

חזית האתר — Frontend

Frontend

מה זה: החלק שרץ בדפדפן של המשתמש: מסכים, JavaScript, רכיבי UI, בקשות Network וקוד צד לקוח.
למה זה חשוב: כל מה שמגיע ל-Frontend נחשב גלוי למשתמש מבחינת אבטחה, גם אם לא מוצג בעיצוב.
דוגמה: מידע שמוחזר ב-Network Response אבל מוסתר מהמסך עדיין נחשב חשוף.
מה לבדוק / איך למנוע: פותחים DevTools ובודקים Console, Network, Local Storage ו-Cookies כדי לראות מה באמת מגיע לדפדפן.

3מושגי יסוד

צד שרת — Backend

Backend

מה זה: הלוגיקה שרצה בצד שרת, API, Edge Function או שירות backend, ולא בדפדפן של המשתמש.
למה זה חשוב: החלטות רגישות כמו הרשאות, פעולות אדמין וגישה לדאטה צריכות להיאכף בצד שרת או DB, לא רק במסך.
דוגמה: כפתור “מחק משתמש” יכול להיות מוסתר ב-UI, אבל ה-Backend חייב לחסום פעולה כזו למי שאינו אדמין.
מה לבדוק / איך למנוע: בודקים שהפעולה עצמה חסומה, לא רק שהכפתור אינו מופיע.

4מושגי יסוד

ממשק תכנות יישומים — API

API = Application Programming Interface

מה זה: דרך מוסדרת שבה האתר מדבר עם שרת, Supabase או שירותים חיצוניים באמצעות בקשות ותשובות.
למה זה חשוב: רבות מהחולשות לא נראות בעיצוב האתר אלא בבקשות API ובמידע שחוזר מהשרת.
דוגמה: האתר מציג רק 3 שדות במסך, אבל Response של ה-API מחזיר גם אימייל, role ו-user_id של משתמשים אחרים.
מה לבדוק / איך למנוע: בודקים Network/Fetch/XHR ורואים אילו Endpoints נקראים ומה חוזר מהם.

5מושגי יסוד

נקודת קצה — Endpoint

Endpoint

מה זה: כתובת או פעולה ספציפית ב-API שמחזירה מידע או מבצעת פעולה.
למה זה חשוב: כל Endpoint הוא נקודת בדיקה אפשרית: האם צריך Login? האם נבדקת הרשאה? האם הוא מחזיר יותר מדי מידע?
דוגמה: /api/requests מחזיר רשימת בקשות; /api/admin/users אמור להיות נגיש רק לאדמין.
מה לבדוק / איך למנוע: עוברים על ה-Endpoints שנראים ב-Network ומסמנים ציבורי/פרטי/אדמין.

6מושגי יסוד

בקשה — Request

Request

מה זה: המידע שהדפדפן או כלי בדיקה שולחים לשרת או ל-API.
למה זה חשוב: בקשה יכולה לכלול מזהה משתמש, מזהה בקשה, headers, token, body ועוד. לפעמים שם רואים על מה האפליקציה סומכת.
דוגמה: בקשה לעדכון פרופיל מכילה owner_user_id שנשלח מהדפדפן; זה עלול להיות סימן לסיכון אם השרת סומך עליו.
מה לבדוק / איך למנוע: מנתחים בקשות ב-DevTools או בכלי API ומוודאים שהשרת לא סומך על ערכים רגישים מהלקוח בלבד.

7מושגי יסוד

תשובה — Response

Response

מה זה: המידע שהשרת מחזיר לדפדפן אחרי בקשה.
למה זה חשוב: חשיפות רבות קורות כי ה-Response מחזיר מידע פנימי או מידע של משתמשים אחרים גם אם המסך לא מציג אותו.
דוגמה: טופס יצירת קשר מחזיר debug_token, role ו-internal_id למשתמש.
מה לבדוק / איך למנוע: בודקים Response Preview/Response ב-Network ומוודאים שחוזר רק מידע שהמשתמש באמת צריך לראות.

8מושגי יסוד

קוד סטטוס — Status Code

HTTP Status Code

מה זה: מספר שמייצג את תוצאת הבקשה: הצלחה, חוסר הרשאה, שגיאה וכו׳.
למה זה חשוב: קוד סטטוס עוזר להבין אם מערכת באמת חוסמת גישה או רק מציגה מסך יפה.
דוגמה: 200 = הצליח; 401 = לא מחובר; 403 = אין הרשאה; 404 = לא נמצא; 500 = שגיאת שרת.
מה לבדוק / איך למנוע: כשמשתמש לא מורשה ניגש למשאב פרטי, מצפים לחסימה ברורה כמו 403 או התנהגות שקולה — לא 200 עם מידע רגיש.

9מושגי יסוד

אכיפה בצד לקוח — Client-Side Enforcement

Client-Side Enforcement

מה זה: הגנה שמתרחשת רק בדפדפן: הסתרת כפתור, תפריט, route או תנאי JavaScript.
למה זה חשוב: זו שכבת UX, לא אבטחה מלאה. משתמש מתקדם או שגיאת לוגיקה יכולים לעקוף אותה.
דוגמה: המערכת לא מציגה כפתור Admin למשתמש רגיל, אבל URL ישיר עדיין נפתח.
מה לבדוק / איך למנוע: לא מסתפקים בבדיקת UI. בודקים ישירות שהמידע/פעולה חסומים בצד שרת או בסיס נתונים.

10מושגי יסוד

אכיפה בצד שרת — Server-Side Enforcement

Server-Side Enforcement

מה זה: הגנה שנאכפת בשרת, API, Edge Function או בסיס הנתונים לפני שמידע חוזר למשתמש.
למה זה חשוב: זו ההגנה החשובה באמת עבור הרשאות ודאטה רגיש.
דוגמה: ה-API בודק שה-request.owner_user_id שווה למשתמש המחובר לפני החזרת פרטי הבקשה.
מה לבדוק / איך למנוע: מנסים פעולה/גישה כמשתמש לא מורשה ומוודאים שהשרת לא מחזיר את המידע.

11מושגי יסוד

אימות זהות — Authentication (AuthN)

AuthN = Authentication

מה זה: בדיקה מי המשתמש: האם הוא מחובר, מי הוא, ומה הזהות שלו במערכת.
למה זה חשוב: Login הוא תנאי בסיסי, אבל הוא לא מספיק. אחרי שיודעים מי המשתמש צריך לבדוק מה מותר לו לעשות.
דוגמה: דניאל התחבר בהצלחה למערכת.
מה לבדוק / איך למנוע: בודקים Login/Logout, session, Reset Password, והאם עמודים פרטיים דורשים משתמש מחובר.

12מושגי יסוד

הרשאה — Authorization (AuthZ)

AuthZ = Authorization

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

13מושגי יסוד

סשן — Session

Session

מה זה: מצב התחברות מתמשך שמאפשר למערכת לזהות את המשתמש בין עמודים ובקשות.
למה זה חשוב: אם session מנוהל לא נכון, משתמש יכול להישאר מחובר מדי, להיחסם לא נכון, או לאבד הרשאות בצורה מסוכנת.
דוגמה: משתמש מתחבר פעם אחת ואז יכול לעבור בין Dashboard, מסמכים ופרופיל בלי להתחבר מחדש.
מה לבדוק / איך למנוע: בודקים Logout, פתיחה בחלון פרטי, שינוי role, והאם session מתנהג בצורה צפויה.

14מושגי יסוד

עוגייה — Cookie

HTTP Cookie

מה זה: פיסת מידע שהדפדפן שומר ושולח לאתר בבקשות עתידיות.
למה זה חשוב: Cookies משמשות הרבה פעמים ל-session ולכן צריך להגן עליהן באמצעות הגדרות מתאימות.
דוגמה: Cookie שמייצגת session של משתמש מחובר.
מה לבדוק / איך למנוע: בודקים ב-Application > Cookies אם קיימות הגדרות כמו HttpOnly, Secure ו-SameSite כאשר רלוונטי.

15מושגי יסוד

אחסון מקומי — Local Storage

Local Storage

מה זה: אזור אחסון בדפדפן שבו האתר יכול לשמור נתונים בצד לקוח.
למה זה חשוב: כל מה שנשמר שם גלוי למשתמש בדפדפן. לא שמים שם secrets או מידע רגיש שלא צריך להיות נגיש.
דוגמה: שמירת token רגיש או מידע פרטי מלא ב-Local Storage עלולה להיות בעייתית.
מה לבדוק / איך למנוע: פותחים DevTools > Application > Local Storage ובודקים שאין שם secrets או מידע מיותר.

16מושגי יסוד

טוקן — Token

Security Token

מה זה: ערך שמייצג זהות, הרשאה או גישה זמנית לשירות.
למה זה חשוב: Tokens יכולים לתת גישה לפעולות או מידע. צריך להבין איפה הם נשמרים ומה היקף ההרשאה שלהם.
דוגמה: Access token שמאפשר לקרוא API בשם המשתמש.
מה לבדוק / איך למנוע: לא משתפים tokens, לא מדביקים אותם בצ׳אט, ובודקים שהם לא מודפסים ל-Console או ל-Response.

17מושגי יסוד

טוקן JWT

JWT = JSON Web Token

מה זה: פורמט נפוץ לטוקן שיכול להכיל Claims על המשתמש, כמו מזהה, תפקיד וזמן תפוגה.
למה זה חשוב: JWT עוזר להבין מי המשתמש, אבל אסור לסמוך על מידע מהדפדפן בלי אימות ואכיפה בצד שרת/DB.
דוגמה: JWT עשוי להכיל user_id או role.
מה לבדוק / איך למנוע: בודקים שהמערכת לא מאפשרת למשתמש לקבוע לעצמו role או user_id דרך הלקוח.

18מושגי יסוד

תפקיד משתמש — Role

Role

מה זה: סיווג המשתמש לפי הרשאות או אחריות במערכת.
למה זה חשוב: בפורטל Lovable מורכב, טעות ב-Role יכולה לפתוח אזורי ניהול או דאטה רגיש למשתמשים לא נכונים.
דוגמה: User, Provider, Manager, Admin.
מה לבדוק / איך למנוע: מגדירים טבלת הרשאות ברורה לכל Role ובודקים אותה בפועל עם משתמשי דמו.

19מושגי יסוד

בקרת גישה לפי תפקידים — RBAC

RBAC = Role-Based Access Control

מה זה: מודל שבו הרשאות נקבעות לפי תפקיד המשתמש.
למה זה חשוב: עוזר לעשות סדר באפליקציות עם User, Manager ו-Admin, אבל חייב להיות נאכף בפועל.
דוגמה: Manager יכול לראות פניות, Admin יכול לנהל משתמשים, User רואה רק את עצמו.
מה לבדוק / איך למנוע: בודקים שכל Role באמת מקבל רק את הפעולות והמידע שהוגדרו לו.

20מושגי יסוד

עיקרון ההרשאה המינימלית — Least Privilege

Principle of Least Privilege

מה זה: כל משתמש, שירות או מפתח מקבל רק את ההרשאות הנדרשות לו — לא יותר.
למה זה חשוב: מפחית נזק במקרה של טעות, פריצה או חשיפת key.
דוגמה: נציג שירות לא צריך לראות את כל הטבלאות או לשנות הרשאות אדמין.
מה לבדוק / איך למנוע: בכל Role וכל API key שואלים: האם ההרשאה הזו באמת נחוצה?

21בקרת גישה והרשאות

בקרת גישה שבורה — Broken Access Control

Broken Access Control

מה זה: מצב שבו משתמש מצליח לגשת למידע או לבצע פעולה שלא אמורים להיות זמינים לו.
למה זה חשוב: זה אחד הסיכונים המרכזיים באפליקציות עם משתמשים, ובמיוחד באפליקציות שנבנו מהר עם AI.
דוגמה: משתמש רגיל רואה מסמך של משתמש אחר או נכנס למסך ניהול.
מה לבדוק / איך למנוע: בודקים עם כמה משתמשים ו-Roles, ומוודאים שהחסימה נאכפת בצד שרת/DB.

22בקרת גישה והרשאות

גישה ישירה לא מאובטחת לאובייקט — IDOR

IDOR = Insecure Direct Object Reference

מה זה: חולשה שבה משתמש ניגש למשאב לפי מזהה ישיר, והמערכת לא בודקת שהמשאב שייך לו.
למה זה חשוב: נפוצה מאוד בפורטלים עם URLs כמו /requests/1001. סורקים אוטומטיים לא תמיד מזהים אותה כי היא תלויה בלוגיקה העסקית.
דוגמה: דניאל נכנס ל-/requests/REQ-2001 ורואה בקשה של מאיה.
מה לבדוק / איך למנוע: בודקים משאבים עם משתמש א׳ ומשתמש ב׳. תיקון עקרוני: בדיקת ownership בצד שרת/RLS.

23בקרת גישה והרשאות

הרשאה שבורה ברמת אובייקט — BOLA

BOLA = Broken Object Level Authorization

מה זה: גרסה נפוצה בעולם API לבעיה שבה API מחזיר אובייקט לפי מזהה בלי לבדוק הרשאת גישה לאותו אובייקט.
למה זה חשוב: חשוב במיוחד ל-API, Supabase ו-Edge Functions.
דוגמה: GET /api/requests/REQ-2001 מחזיר מידע של מאיה למשתמש דניאל.
מה לבדוק / איך למנוע: לכל קריאת API שמחזירה אובייקט בודקים: האם המשתמש המחובר מורשה לאובייקט הזה?

24בקרת גישה והרשאות

הרשאה שבורה ברמת פעולה — BFLA

BFLA = Broken Function Level Authorization

מה זה: מצב שבו משתמש יכול לבצע פעולה או לגשת לפונקציה שלא מתאימה לתפקיד שלו.
למה זה חשוב: גם אם דאטה פרטי לא נחשף, פעולה רגישה כמו שינוי סטטוס או מחיקה יכולה להיות מסוכנת.
דוגמה: משתמש רגיל מצליח לקרוא לפעולת admin/update-user-role.
מה לבדוק / איך למנוע: בודקים פעולות לפי Role: מי יכול ליצור, לעדכן, למחוק, לאשר, לשנות סטטוס ולנהל משתמשים.

25בקרת גישה והרשאות

בדיקת בעלות — Ownership Check

Ownership Check

מה זה: בדיקה שהמשאב המבוקש באמת שייך למשתמש המחובר או שהוא מורשה אליו.
למה זה חשוב: זו ההגנה המרכזית נגד IDOR/BOLA.
דוגמה: לפני החזרת בקשה, בודקים ש-owner_user_id תואם ל-user_id של המשתמש המחובר.
מה לבדוק / איך למנוע: בכל עמוד Details או API by ID מוודאים שקיימת בדיקת ownership.

26בקרת גישה והרשאות

ריבוי לקוחות במערכת אחת — Multi-Tenancy

Multi-Tenancy

מה זה: מצב שבו אותה מערכת משרתת כמה לקוחות, ארגונים או חשבונות נפרדים.
למה זה חשוב: טעות בהפרדה בין tenants עלולה לחשוף מידע של לקוח אחד ללקוח אחר.
דוגמה: סוכנות אחת רואה לידים של סוכנות אחרת באותו פורטל.
מה לבדוק / איך למנוע: מוסיפים tenant_id/organization_id ובודקים בידוד דאטה בכל שאילתה, policy ו-API.

27בקרת גישה והרשאות

בידוד דיירים/ארגונים — Tenant Isolation

Tenant Isolation

מה זה: הפרדה שמבטיחה שמשתמשים מארגון אחד לא יכולים לראות או לשנות מידע של ארגון אחר.
למה זה חשוב: במערכות B2B זה קריטי לא פחות מהרשאות user_id.
דוגמה: Manager של חברה א׳ לא אמור לראות מסמכים של חברה ב׳.
מה לבדוק / איך למנוע: בודקים לפחות שני ארגונים נפרדים עם משתמשים שונים ומוודאים שאין זליגה ביניהם.

28בקרת גישה והרשאות

לוגיקה עסקית — Business Logic

Business Logic

מה זה: החוקים העסקיים של האפליקציה: מי רשאי לעשות מה, באיזה מצב, ובאיזה סדר.
למה זה חשוב: סריקות אבטחה טכניות לא תמיד מבינות את החוקים האלה ולכן עלולות לפספס חולשות.
דוגמה: רק Manager יכול לאשר בקשה מעל סכום מסוים, אבל משתמש רגיל מצליח לשנות סטטוס ידנית.
מה לבדוק / איך למנוע: מגדירים Abuse Cases ובודקים זרימות עסקיות רגישות עם Roles שונים.

29בקרת גישה והרשאות

מקרה ניצול לרעה — Abuse Case

Abuse Case

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

30בקרת גישה והרשאות

מודל איומים — Threat Modeling

Threat Modeling

מה זה: תהליך חשיבה מסודר שממפה נכסים, משתמשים, איומים, נקודות כניסה והגנות.
למה זה חשוב: באתרי AI זה מאפשר לעצור רגע לפני פרודקשן ולהבין מה באמת צריך לבדוק.
דוגמה: מיפוי: יש מסמכים פרטיים, API, משתמשים, אדמין ו-Supabase — לכן צריך בדיקות הרשאה ו-Storage.
מה לבדוק / איך למנוע: מכינים טבלת נכסים, משתמשים, תרחישי סיכון ובדיקות נדרשות.

31Supabase, Lovable ונתונים

אימות משתמשים ב — Supabase Auth

Supabase Authentication

מה זה: שירות האימות של Supabase לניהול הרשמה, התחברות, סשנים ומשתמשים.
למה זה חשוב: Lovable משתמשת לעיתים ב-Supabase Auth, אבל Login בלבד לא מגן על הטבלאות ללא RLS/Policies.
דוגמה: משתמש מחובר דרך Supabase Auth אך טבלת requests פתוחה מדי.
מה לבדוק / איך למנוע: בודקים Auth Redirect URLs, משתמשי בדיקה, sessions והאם הרשאות הטבלאות מתבססות על המשתמש המחובר.

32Supabase, Lovable ונתונים

אבטחה ברמת שורה — RLS

RLS = Row Level Security

מה זה: מנגנון שמאפשר לבסיס הנתונים להחזיר או לשנות רק שורות שהמשתמש מורשה אליהן.
למה זה חשוב: זה אחד הכלים הכי חשובים למניעת חשיפת מידע בין משתמשים ב-Supabase.
דוגמה: דניאל מקבל רק rows שבהן owner_user_id = user_a.
מה לבדוק / איך למנוע: מוודאים ש-RLS פעיל בטבלאות רגישות ושקיימות policies מתאימות ל-SELECT/INSERT/UPDATE/DELETE.

33Supabase, Lovable ונתונים

מדיניות הרשאה — Policy

Database/RLS Policy

מה זה: כלל שמגדיר מי יכול לקרוא, ליצור, לעדכן או למחוק מידע בטבלה.
למה זה חשוב: Policy רחבה מדי יכולה להפוך טבלה פרטית לציבורית בפועל.
דוגמה: User can read own requests; Admin can read all requests.
מה לבדוק / איך למנוע: קוראים policies ומתרגמים אותן לעברית פשוטה: מי רשאי לעשות מה ובאיזה תנאי.

34Supabase, Lovable ונתונים

טבלה ציבורית — Public Table

Public Table

מה זה: טבלה שמכילה מידע שמותר להיות נגיש לציבור או למשתמשים רבים.
למה זה חשוב: לא כל טבלה צריכה להיות פרטית, אבל צריך להחליט במודע ולא בטעות.
דוגמה: טבלת articles או public_pages.
מה לבדוק / איך למנוע: מסמנים טבלאות ציבוריות ומוודאים שאין בהן מידע אישי, פנימי או רגיש.

35Supabase, Lovable ונתונים

טבלה פרטית — Private Table

Private Table

מה זה: טבלה שמכילה מידע שאמור להיות מוגן לפי משתמש, Role או ארגון.
למה זה חשוב: רוב הטבלאות בפורטל לקוחות הן פרטיות ודורשות RLS.
דוגמה: profiles, documents, messages, requests, orders, leads.
מה לבדוק / איך למנוע: לכל טבלה פרטית בודקים RLS, policies, ownership ו-Role access.

36Supabase, Lovable ונתונים

מפתח אנונימי — Anon Key

Supabase Anonymous Key

מה זה: מפתח ציבורי יחסית שמשמש את ה-Frontend כדי לתקשר עם Supabase תחת מגבלות RLS.
למה זה חשוב: הוא יכול להופיע בצד לקוח, אבל לא אמור לאפשר גישה חופשית לדאטה. ההגנה האמיתית היא RLS.
דוגמה: האפליקציה משתמשת ב-anon key לקריאת נתונים ציבוריים או נתונים מורשים.
מה לבדוק / איך למנוע: בודקים שלא משתמשים ב-anon key כתחליף להרשאות וש-RLS אכן מגביל גישה.

37Supabase, Lovable ונתונים

מפתח תפקיד שירות — Service Role Key

Supabase Service Role Key

מה זה: מפתח רגיש מאוד של Supabase שמסוגל לעקוף RLS ולבצע פעולות חזקות.
למה זה חשוב: אסור שיופיע בצד לקוח. חשיפה שלו יכולה לאפשר גישה רחבה מאוד לדאטה.
דוגמה: service_role key שמופיע בקוד frontend, ב-Console או ב-repository ציבורי.
מה לבדוק / איך למנוע: אם נחשף: מחליפים key, בודקים שימושים, מעבירים לצד שרת/Environment Variables ומבצעים review.

38Supabase, Lovable ונתונים

אחסון קבצים — Storage Bucket

Storage Bucket

מה זה: אזור אחסון לקבצים כמו תמונות, מסמכים, חוזים וקבצי משתמשים.
למה זה חשוב: קבצים הם מקור נפוץ לחשיפת מידע, במיוחד אם bucket ציבורי בטעות.
דוגמה: מסמך זהות דמו מאוחסן ב-bucket שנגיש לכל מי שמכיר URL.
מה לבדוק / איך למנוע: ממפים buckets, public/private, סוגי קבצים, וכללי גישה.

39Supabase, Lovable ונתונים

Bucket ציבורי — Public Bucket

Public Storage Bucket

מה זה: אזור קבצים שניתן לגשת לקבצים בו ללא הרשאה פרטנית.
למה זה חשוב: מתאים לתמונות ציבוריות, לא למסמכים פרטיים.
דוגמה: תמונות בלוג ציבוריות.
מה לבדוק / איך למנוע: מוודאים ש-public bucket לא מכיל מסמכי לקוחות, קבצים פנימיים או מידע אישי.

40Supabase, Lovable ונתונים

Bucket פרטי — Private Bucket

Private Storage Bucket

מה זה: אזור קבצים שנגיש רק לפי הרשאות.
למה זה חשוב: נדרש למסמכים אישיים, קבצי לקוחות, חוזים ותוכן רגיש.
דוגמה: משתמש רואה רק קבצים שלו דרך policy או signed URL.
מה לבדוק / איך למנוע: בודקים קובץ של משתמש א׳ מתוך משתמש ב׳ ומוודאים שהגישה נחסמת.

41Supabase, Lovable ונתונים

קישור חתום — Signed URL

Signed URL

מה זה: קישור זמני ומוגבל לקובץ פרטי.
למה זה חשוב: מאפשר לתת גישה לקובץ בלי להפוך את כל ה-bucket לציבורי.
דוגמה: קישור למסמך תקף ל-10 דקות למשתמש מורשה.
מה לבדוק / איך למנוע: בודקים שהקישור מוגבל בזמן, לא נוצר למי שאינו מורשה, ולא נשמר במקומות ציבוריים.

42Supabase, Lovable ונתונים

פונקציית קצה — Edge Function

Edge Function

מה זה: פונקציה שרצה בצד שרת/Edge ומבצעת לוגיקה או תקשורת עם שירותים חיצוניים.
למה זה חשוב: מקום נכון לשים פעולות רגישות, אבל חייב לכלול בדיקת auth/authorization.
דוגמה: Edge Function ששולחת אימייל או מעדכנת סטטוס בקשה.
מה לבדוק / איך למנוע: בודקים שהיא דורשת משתמש/Role מתאים ולא מחזירה מידע פנימי מיותר.

43Supabase, Lovable ונתונים

משתני סביבה — Environment Variables (ENV)

ENV = Environment Variables

מה זה: הגדרות ומפתחות שנשמרים מחוץ לקוד, לפי סביבת הרצה.
למה זה חשוב: עוזרים להפריד secrets מהקוד ולנהל Preview/Production בצורה בטוחה.
דוגמה: SUPABASE_URL, SUPABASE_ANON_KEY, STRIPE_SECRET_KEY.
מה לבדוק / איך למנוע: מוודאים שמפתחות רגישים נמצאים רק בסביבת שרת/Platform ולא בקוד צד לקוח.

44Supabase, Lovable ונתונים

Webhook

מה זה: קריאה אוטומטית משירות חיצוני לאפליקציה כאשר קורה אירוע.
למה זה חשוב: Webhook לא מאומת יכול לאפשר עדכון מידע לא מורשה או קבלת אירועים מזויפים.
דוגמה: שירות תשלומים שולח הודעה שהעסקה הצליחה.
מה לבדוק / איך למנוע: בודקים חתימה/secret של webhook, ולוגיקה שמוודאת שהאירוע אמיתי ורלוונטי.

45חולשות וסיכוני OWASP

OWASP Top 10

OWASP = Open Worldwide Application Security Project Top 10

מה זה: רשימת סיכוני אבטחת Web מרכזיים שמפורסמת על ידי OWASP ומשמשת כנקודת ייחוס מקצועית.
למה זה חשוב: נותנת שפה מקצועית לקורס ומחברת בעיות כמו Broken Access Control, Injection ו-Security Misconfiguration לעולם מוכר.
דוגמה: Broken Access Control הוא אחד הסיכונים המרכזיים ברשימה.
מה לבדוק / איך למנוע: משתמשים ברשימה כמפה, אבל מתמקדים במה שרלוונטי לאתרי AI ו-Lovable.

46חולשות וסיכוני OWASP

הזרקה — Injection

Injection

מה זה: מצב שבו קלט משתמש משפיע בצורה לא בטוחה על שאילתה, פקודה, Prompt או פעולה פנימית.
למה זה חשוב: כל מקום שבו משתמש מזין טקסט או קובץ הוא נקודת בדיקה.
דוגמה: טופס שמכניס קלט ישירות לשאילתה או ל-Prompt ללא בקרה מתאימה.
מה לבדוק / איך למנוע: משתמשים ב-validation, sanitization, ספריות בטוחות, הרשאות מוגבלות ובדיקות קלט. לא מדגימים ניצול לא מורשה.

47חולשות וסיכוני OWASP

הזרקת - SQL Injection - SQLi

SQLi = Structured Query Language Injection

מה זה: סוג של Injection שבו קלט משפיע על שאילתת SQL בצורה שעלולה לחשוף או לשנות מידע.
למה זה חשוב: פחות נפוץ אם עובדים נכון עם Supabase/ORM, אבל חשוב להכיר כשיש שאילתות ידניות.
דוגמה: קלט מטופס נכנס לשאילתת SQL ללא פרמטרים בטוחים.
מה לבדוק / איך למנוע: משתמשים בשאילתות פרמטריות, APIs בטוחים ו-RLS; לא בונים SQL מקלט גולמי.

48חולשות וסיכוני OWASP

הזרקת פקודות — Command Injection

Command Injection

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

49חולשות וסיכוני OWASP

הזרקת — Prompt Injection

Prompt Injection

מה זה: מצב שבו קלט משתמש משנה את התנהגות מודל AI או גורם לו להתעלם מהנחיות.
למה זה חשוב: חשוב לאפליקציות שמשלבות AI, Claude Code או שירותי LLM.
דוגמה: משתמש מזין טקסט שגורם למערכת AI להחזיר מידע או לבצע פעולה שלא התכוונו אליה.
מה לבדוק / איך למנוע: מפרידים בין נתוני משתמש להוראות מערכת, מגבילים פעולות, לא נותנים למודל גישה חופשית ל-secrets, ומאמתים תוצאות בצד שרת.

50חולשות וסיכוני OWASP

סקריפטינג בין אתרים — XSS

XSS = Cross-Site Scripting

מה זה: חולשה שבה תוכן לא בטוח שמקורו במשתמש מוצג או מורץ אצל משתמשים אחרים.
למה זה חשוב: באתרים עם תוכן משתמשים, הודעות, תגובות או תיאורים, זה סיכון נפוץ.
דוגמה: משתמש מזין תוכן שמוצג לאחרים בלי ניקוי מתאים.
מה לבדוק / איך למנוע: משתמשים ב-escaping, sanitization, frameworks בטוחים ו-CSP. בודקים שדות שמוצגים חזרה למשתמשים.

51חולשות וסיכוני OWASP

זיוף בקשה בין אתרים — CSRF

CSRF = Cross-Site Request Forgery

מה זה: מצב שבו אתר חיצוני גורם לדפדפן של משתמש מחובר לבצע פעולה באתר אחר.
למה זה חשוב: רלוונטי בעיקר כאשר פעולות מבוססות cookies/session ללא הגנות מתאימות.
דוגמה: משתמש מחובר, ואתר אחר מנסה לגרום לדפדפן שלו לשלוח פעולה רגישה.
מה לבדוק / איך למנוע: בודקים שימוש ב-SameSite cookies, CSRF tokens או מנגנוני auth שמתאימים לארכיטקטורה.

52חולשות וסיכוני OWASP

זיוף בקשה מצד שרת — SSRF

SSRF = Server-Side Request Forgery

מה זה: מצב שבו השרת נגרם לגשת לכתובות או שירותים שלא אמור לגשת אליהם.
למה זה חשוב: רלוונטי אם האתר מקבל URL מהמשתמש ומוריד/קורא ממנו תוכן בצד שרת.
דוגמה: שדה “ייבוא מקישור” שגורם לשרת לגשת לכתובות פנימיות.
מה לבדוק / איך למנוע: מגבילים כתובות מותרות, חוסמים רשתות פנימיות, ולא סומכים על URLs מקלט משתמש.

53חולשות וסיכוני OWASP

הגדרות אבטחה שגויות — Security Misconfiguration

Security Misconfiguration

מה זה: הגדרה לא נכונה של שרת, DB, Storage, Headers, CORS, Debug או הרשאות.
למה זה חשוב: באתרי AI זה נפוץ כי הרבה הגדרות נוצרות מהר או נשארות ברירת מחדל.
דוגמה: RLS כבוי, bucket ציבורי, CORS פתוח מדי, debug פעיל בפרודקשן.
מה לבדוק / איך למנוע: משתמשים בצ׳קליסט Production, SecurityHeaders, Supabase Advisor ובדיקות ידניות.

54חולשות וסיכוני OWASP

רכיבים פגיעים או מיושנים — Vulnerable and Outdated Components

Vulnerable and Outdated Components

מה זה: ספריות, חבילות או רכיבים עם חולשות ידועות או גרסאות ישנות.
למה זה חשוב: רלוונטי במיוחד כשיש GitHub/package.json ותלויות npm.
דוגמה: חבילת npm עם CVE פעיל.
מה לבדוק / איך למנוע: בודקים Dependabot/SCA, מעדכנים גרסאות, ובודקים שהעדכון לא שובר את האתר.

55חולשות וסיכוני OWASP

כשלי זיהוי ואימות — Identification and Authentication Failures

Identification and Authentication Failures

מה זה: בעיות במנגנוני Login, Session, Reset Password, MFA וניהול משתמשים.
למה זה חשוב: גם אם הרשאות נכונות, Auth חלש עלול לאפשר כניסה או שימוש לא רצוי.
דוגמה: Reset password לא מוגדר נכון או session לא פוקע.
מה לבדוק / איך למנוע: בודקים זרימות Login/Logout/Reset, חוזק סיסמאות, MFA אם רלוונטי והתנהגות session.

56חולשות וסיכוני OWASP

כשלי קריפטוגרפיה — Cryptographic Failures

Cryptographic Failures

מה זה: בעיות בהצפנה, שמירת מידע רגיש, TLS, סיסמאות או העברת מידע.
למה זה חשוב: בדרך כלל בקורס הזה ניגע בזה ברמת Production: HTTPS, secrets ומידע רגיש.
דוגמה: אתר ללא HTTPS או מידע אישי שנשלח/נשמר בלי הגנה מתאימה.
מה לבדוק / איך למנוע: מוודאים HTTPS/TLS, לא שומרים סודות בדפדפן, ומשתמשים בשירותי Auth מוכרים במקום פתרונות מאולתרים.

57חולשות וסיכוני OWASP

כשלי שלמות תוכנה ודאטה — Software and Data Integrity Failures

Software and Data Integrity Failures

מה זה: סיכונים שנובעים מתהליך build/deploy לא בטוח, dependencies לא מאומתות או שרשרת אספקה.
למה זה חשוב: רלוונטי לפרויקטים עם GitHub, CI/CD וחבילות צד שלישי.
דוגמה: עדכון dependency לא מבוקר מכניס התנהגות לא רצויה.
מה לבדוק / איך למנוע: משתמשים ב-PR review, Dependabot, lock files וסריקות לפני deploy.

58חולשות וסיכוני OWASP

כשלי ניטור ורישום — Security Logging and Monitoring Failures

Security Logging and Monitoring Failures

מה זה: חוסר יכולת לדעת מה קרה במערכת אחרי אירוע, שגיאה או ניסיון גישה חריג.
למה זה חשוב: בלי logs/monitoring קשה לגלות בעיות או להבין השפעה.
דוגמה: אין תיעוד של ניסיונות כניסה או גישה לעמודים רגישים.
מה לבדוק / איך למנוע: מגדירים logs בסיסיים, error tracking והתראות לאירועים חריגים בפרודקשן.

59חולשות וסיכוני OWASP

חשיפת סודות — Secrets Exposure

Secrets Exposure

מה זה: מצב שבו מפתחות, tokens, סיסמאות או credentials מופיעים במקום גלוי או לא מוגן.
למה זה חשוב: אחת הבעיות הכי מסוכנות בפרויקטים שנבנים מהר, במיוחד עם AI ו-GitHub.
דוגמה: OpenAI key או Supabase service role key מופיע ב-Frontend או repo.
מה לבדוק / איך למנוע: מריצים secret scanning, בודקים ENV, מחליפים מפתחות שנחשפו, ומעבירים סודות לצד שרת.

60חולשות וסיכוני OWASP

חשיפת מידע — Information Disclosure

Information Disclosure

מה זה: החזרת או הצגת מידע שלא אמור להיות גלוי למשתמש.
למה זה חשוב: זה יכול להיות מידע אישי, debug data, IDs, roles, הודעות שגיאה, paths פנימיים או תגובות API רחבות מדי.
דוגמה: Response של טופס מחזיר internal_id ו-debug_token.
מה לבדוק / איך למנוע: בודקים Responses, Console, error messages ועמודים פרטיים. מחזירים רק מידע שנדרש להצגה.

61חולשות וסיכוני OWASP

מצב Debug פעיל — Debug Mode

Debug Mode

מה זה: מצב פיתוח שמציג מידע פנימי או מפורט מדי.
למה זה חשוב: בפרודקשן זה עלול לחשוף פרטים טכניים שמסייעים להבין את המערכת.
דוגמה: שגיאה באתר מציגה stack trace או משתני סביבה.
מה לבדוק / איך למנוע: מוודאים ש-debug כבוי בפרודקשן וששגיאות מוצגות בצורה כללית למשתמש.

62חולשות וסיכוני OWASP

טיפול בשגיאות — Error Handling

Error Handling

מה זה: האופן שבו המערכת מציגה ומתעדת שגיאות.
למה זה חשוב: שגיאות צריכות לעזור למשתמש בלי לחשוף מידע פנימי.
דוגמה: במקום “Database connection failed at...” מציגים “אירעה שגיאה, נסו שוב מאוחר יותר”.
מה לבדוק / איך למנוע: בודקים טפסים ופעולות כושלות ורואים מה מוצג במסך ומה נרשם בלוגים.

63חולשות וסיכוני OWASP

הגבלת קצב — Rate Limiting

Rate Limiting

מה זה: הגבלת כמות בקשות שמשתמש/כתובת יכולים לבצע בזמן מסוים.
למה זה חשוב: חשוב לטפסים, Login, API ופעולות יקרות כדי לצמצם abuse וספאם.
דוגמה: טופס שניתן לשלוח מאות פעמים בדקה ללא מגבלה.
מה לבדוק / איך למנוע: מוסיפים מגבלות לפי IP/משתמש/פעולה, CAPTCHA במידת הצורך, וניטור חריגות.

64חולשות וסיכוני OWASP

ניסיונות התחברות חוזרים — Brute Force

Brute Force

מה זה: ניסיון שיטתי לנחש סיסמאות או codes באמצעות הרבה ניסיונות.
למה זה חשוב: רלוונטי ל-Login, reset codes וטפסים רגישים.
דוגמה: אין הגבלה על ניסיונות התחברות כושלים.
מה לבדוק / איך למנוע: מוסיפים rate limiting, lockout זהיר, MFA והתראות לניסיונות חריגים.

65חולשות וסיכוני OWASP

שיתוף משאבים בין מקורות — CORS

CORS = Cross-Origin Resource Sharing

מה זה: מנגנון דפדפן שמגדיר מאילו דומיינים מותר לקרוא למשאבים/ API.
למה זה חשוב: CORS חשוב אבל אינו תחליף להרשאות. גם API עם CORS “סגור” חייב לבדוק משתמש ו-Role.
דוגמה: Access-Control-Allow-Origin: * על API רגיש יכול להיות סימן להגדרה רחבה מדי.
מה לבדוק / איך למנוע: בודקים CORS ב-headers ומוודאים שאין הסתמכות עליו במקום AuthZ אמיתי.

66בדיקות וכלי אבטחה

בדיקת אבטחה סטטית — SAST

SAST = Static Application Security Testing

מה זה: סריקת קוד בלי להריץ את האפליקציה, כדי למצוא דפוסים בעייתיים.
למה זה חשוב: שימושי כשיש GitHub/קוד, למשל Claude Code או export מ-Lovable.
דוגמה: CodeQL או Semgrep מזהים שימוש לא בטוח בקוד.
מה לבדוק / איך למנוע: מריצים סריקה, קוראים ממצאים, מסמנים false positives ומתקנים מה שרלוונטי.

67בדיקות וכלי אבטחה

בדיקת אבטחה דינמית — DAST

DAST = Dynamic Application Security Testing

מה זה: בדיקה של האפליקציה כשהיא רצה, מבחוץ, דרך HTTP ודפדפן.
למה זה חשוב: שימושי גם בלי גישה לקוד, אבל לא תמיד מזהה לוגיקה עסקית והרשאות בין משתמשים.
דוגמה: ZAP בודק headers, קונפיגורציות ובעיות נפוצות באתר חי או staging.
מה לבדוק / איך למנוע: מריצים רק על אתר בבעלותך/באישור, קוראים תוצאות בזהירות ומאמתים ידנית.

68בדיקות וכלי אבטחה

בדיקת אבטחה אינטראקטיבית — IAST

IAST = Interactive Application Security Testing

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

69בדיקות וכלי אבטחה

ניתוח רכיבי תוכנה — SCA

SCA = Software Composition Analysis

מה זה: בדיקת ספריות ותלויות צד שלישי כדי לזהות גרסאות פגיעות או מיושנות.
למה זה חשוב: בפרויקטים עם npm/package.json זה חלק חשוב מהבדיקה.
דוגמה: חבילת React/Node עם advisory פעיל.
מה לבדוק / איך למנוע: משתמשים ב-Dependabot, npm audit או כלים דומים, ומעדכנים בזהירות.

70בדיקות וכלי אבטחה

סריקת סודות — Secret Scanning

Secret Scanning

מה זה: חיפוש מפתחות, tokens ו-credentials בקוד, היסטוריית Git או קבצים.
למה זה חשוב: קריטי כשעובדים עם AI שמייצר קוד ועלול לשלב מפתחות במקומות לא נכונים.
דוגמה: GitHub מזהה API key שהועלה ל-repository.
מה לבדוק / איך למנוע: מחליפים מפתח שנחשף, מסירים מהקוד, מוסיפים ל-ENV ומוודאים שלא נשאר בהיסטוריה רלוונטית.

71בדיקות וכלי אבטחה

סריקת קוד — Code Scanning

Code Scanning

מה זה: סריקה שמנתחת קוד כדי למצוא בעיות אבטחה, באגים או דפוסים מסוכנים.
למה זה חשוב: מוסיף שכבת בדיקה למי שיש GitHub.
דוגמה: GitHub Code Scanning מציג alert על קוד בעייתי.
מה לבדוק / איך למנוע: קוראים alert, בודקים רלוונטיות, מתקנים ומבצעים commit/PR מסודר.

72בדיקות וכלי אבטחה

סריקת תלויות — Dependency Scanning

Dependency Scanning

מה זה: בדיקה של חבילות צד שלישי מול מאגרי חולשות ידועות.
למה זה חשוב: חבילות מיושנות הן מקור סיכון גם אם הקוד שלך נראה תקין.
דוגמה: package-lock כולל גרסה עם CVE.
מה לבדוק / איך למנוע: בודקים התראות, משדרגים גרסאות, מריצים בדיקות regression אחרי עדכון.

73בדיקות וכלי אבטחה

סריקת חולשות — Vulnerability Scanning

Vulnerability Scanning

מה זה: בדיקה אוטומטית שמחפשת חולשות או הגדרות בעייתיות.
למה זה חשוב: שימושית להתחלה, אך לא מחליפה בדיקת הרשאות ולוגיקה עסקית.
דוגמה: SecurityHeaders מוצא headers חסרים; ZAP מוצא בעיות נפוצות.
מה לבדוק / איך למנוע: משלבים סריקה עם בדיקה ידנית ודוח מסודר.

74בדיקות וכלי אבטחה

בדיקת חדירות — Penetration Testing (Pentest)

Pentest = Penetration Test

מה זה: בדיקה מקצועית ומעמיקה שמנסה לזהות ולנצל חולשות בסביבה מורשית.
למה זה חשוב: הקורס לא מחליף pentest מלא, אלא מלמד בדיקות מוכנות בסיסיות/בינוניות.
דוגמה: מערכת עם תשלומים, דאטה רגיש או לקוחות רבים עשויה לדרוש pentest מקצועי.
מה לבדוק / איך למנוע: מגדירים Scope, אישור כתוב, גבולות, ודוח. בקורס נשארים בהדגמות מעבדה ובדיקות הגנתיות.

75בדיקות וכלי אבטחה

בדיקה ידנית — Manual Review

Manual Security Review

מה זה: בדיקה אנושית של התנהגות, הרשאות, לוגיקה, דוחות וכלים.
למה זה חשוב: קריטית כי כלים אוטומטיים לא תמיד מבינים מי אמור לראות מה.
דוגמה: בדיקה עם דניאל ומאיה כדי לוודא שאין חשיפת מידע בין משתמשים.
מה לבדוק / איך למנוע: משלבים checklist, כמה משתמשי בדיקה, DevTools ודוח ממצאים.

76בדיקות וכלי אבטחה

ממצא שווא — False Positive

False Positive

מה זה: ממצא שכלי מסמן כבעיה, אבל בפועל אינו מהווה סיכון אמיתי בהקשר הנבדק.
למה זה חשוב: מונע פאניקה ומלמד לקרוא תוצאות בצורה מקצועית.
דוגמה: כלי מסמן header חסר כחמור, אבל האתר הוא דמו פנימי ללא exposure ציבורי.
מה לבדוק / איך למנוע: מאמתים כל ממצא, מתעדים החלטה, ולא מעבירים ללקוח רעש מיותר.

77בדיקות וכלי אבטחה

בעיה שלא זוהתה — False Negative

False Negative

מה זה: בעיה אמיתית שהכלי לא מצא.
למה זה חשוב: חשוב להסביר למה “הסריקה יצאה נקייה” לא שווה “האתר בטוח”.
דוגמה: סורק לא מצא IDOR כי לא יודע שמאיה ודניאל משתמשים שונים.
מה לבדוק / איך למנוע: מבצעים בדיקות ידניות ללוגיקה עסקית והרשאות גם אחרי סריקה אוטומטית.

78בדיקות וכלי אבטחה

רמת חומרה — Severity

Severity

מה זה: דירוג טכני/מקצועי של חומרת ממצא.
למה זה חשוב: עוזר לתעדף טיפול ולהסביר ללקוח מה דחוף.
דוגמה: Critical, High, Medium, Low, Info.
מה לבדוק / איך למנוע: מדרגים לפי השפעה, סבירות, נגישות, היקף מידע וקלות ניצול.

79בדיקות וכלי אבטחה

סיכון — Risk

Risk

מה זה: השילוב בין מה עלול לקרות, כמה זה חמור וכמה סביר שזה יקרה.
למה זה חשוב: לקוח לא צריך רק שם טכני; הוא צריך להבין משמעות עסקית.
דוגמה: “משתמשים עלולים לראות מידע של לקוחות אחרים” הוא risk ברור יותר מ-“IDOR”.
מה לבדוק / איך למנוע: בכל ממצא כותבים: מה נמצא, למה זה חשוב, מה ההשפעה ומה לתקן.

80בדיקות וכלי אבטחה

השפעה — Impact

Impact

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

81בדיקות וכלי אבטחה

סבירות — Likelihood

Likelihood

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

82בדיקות וכלי אבטחה

קלות ניצול — Exploitability

Exploitability

מה זה: כמה קל לנצל את החולשה בפועל.
למה זה חשוב: עוזר להבחין בין בעיה תיאורטית לבעיה דחופה.
דוגמה: אם מספיק לשנות URL כדי לראות מידע אחר, exploitability גבוהה.
מה לבדוק / איך למנוע: לא מפרטים הוראות תקיפה לא מורשית; משתמשים בזה לדירוג ותיקון.

83GitHub Security וקוד

מאגר קוד — Repository (Repo)

Repo = Repository

מה זה: מקום שבו נשמר הקוד, ההיסטוריה, ההגדרות ולעיתים גם קבצי הפרויקט.
למה זה חשוב: אם פרויקט Lovable/Claude Code מחובר ל-GitHub, אפשר להוסיף בדיקות קוד ותלויות.
דוגמה: Repo שמכיל package.json, src, env example ו-README.
מה לבדוק / איך למנוע: בודקים הרשאות repo, visibility, Security tab, secrets ותלויות.

84GitHub Security וקוד

ענף קוד — Branch

Branch

מה זה: קו עבודה נפרד בקוד, למשל main, staging או feature/security-fix.
למה זה חשוב: מאפשר לתקן בעיות בלי לשבור production.
דוגמה: תיקון RLS או route protection נעשה ב-branch נפרד.
מה לבדוק / איך למנוע: עובדים ב-branch, בודקים, ואז ממזגים ל-main אחרי review.

85GitHub Security וקוד

קומיט — Commit

Commit

מה זה: שמירת שינוי בהיסטוריית Git.
למה זה חשוב: היסטוריית commit יכולה להכיל בטעות secrets ולכן חשוב scanning.
דוגמה: commit ישן הכיל API key שנמחק אחר כך מהקובץ, אבל עדיין קיים בהיסטוריה.
מה לבדוק / איך למנוע: מריצים secret scanning ומתייחסים לסוד שנכנס להיסטוריה כחשוף.

86GitHub Security וקוד

בקשת מיזוג — Pull Request (PR)

PR = Pull Request

מה זה: תהליך שמאפשר לבדוק שינוי לפני מיזוגו לענף הראשי.
למה זה חשוב: מקום טוב להריץ בדיקות אבטחה, review וסריקות לפני production.
דוגמה: PR שמתקן הרשאות ומראה בדיקות חוזרות.
מה לבדוק / איך למנוע: מוסיפים checklist ל-PR: AuthZ, RLS, secrets, dependencies, tests.

87GitHub Security וקוד

לשונית אבטחה בגיטהאב — GitHub Security Tab

GitHub Security Tab

מה זה: אזור ב-GitHub שמרכז התראות על קוד, תלויות, secrets ו-advisories.
למה זה חשוב: שכבת בדיקה זמינה למי שמחזיק קוד ב-GitHub.
דוגמה: התראות Dependabot ו-CodeQL מופיעות תחת Security.
מה לבדוק / איך למנוע: בודקים את הלשונית כחלק ממפגש הסריקות ומתרגמים alerts לדוח לקוח.

88GitHub Security וקוד

התראות Dependabot — Dependabot Alerts

Dependabot Alerts

מה זה: התראות של GitHub על dependencies עם חולשות ידועות או עדכונים מומלצים.
למה זה חשוב: עוזר לבוני AI להבין שהבעיה לא תמיד בקוד שהם כתבו אלא בספריות צד שלישי.
דוגמה: Dependabot מסמן חבילת npm בגרסה פגיעה.
מה לבדוק / איך למנוע: בודקים severity, גרסה מתוקנת, השפעה על הפרויקט ומבצעים update/test.

89GitHub Security וקוד

מנוע סריקת קוד של GitHub — CodeQL

CodeQL = Code Query Language

מה זה: כלי/שפה של GitHub לסריקת קוד ולזיהוי דפוסים בעייתיים.
למה זה חשוב: רלוונטי למסלול GitHub מתקדם בקורס.
דוגמה: CodeQL alert על שימוש לא בטוח בנתוני משתמש.
מה לבדוק / איך למנוע: קוראים alert, בודקים אם רלוונטי, מתקנים ומבצעים סריקה חוזרת.

90GitHub Security וקוד

אבטחת גיטהאב מתקדמת — GHAS

GHAS = GitHub Advanced Security

מה זה: סט יכולות אבטחה מתקדמות של GitHub הכולל code scanning, secret scanning ועוד.
למה זה חשוב: לא תמיד זמין לכל תלמיד, אבל מושג מקצועי שכדאי להכיר.
דוגמה: ארגון מפעיל GHAS כדי לסרוק repositories.
מה לבדוק / איך למנוע: להציג כבונוס/המשך מתקדם ולא כתנאי לקורס הראשוני.

91GitHub Security וקוד

ייעוץ אבטחה — Security Advisory

Security Advisory

מה זה: פרסום או התראה על חולשה ידועה בספרייה או מוצר.
למה זה חשוב: עוזר להבין למה כלי SCA מסמן dependency.
דוגמה: ספרייה מפרסמת advisory שממליץ לשדרג לגרסה חדשה.
מה לבדוק / איך למנוע: קוראים summary, affected versions, patched versions ומעדכנים בהתאם.

92GitHub Security וקוד

מזהה חולשה רשמי — CVE

CVE = Common Vulnerabilities and Exposures

מה זה: מזהה רשמי לחולשת אבטחה ידועה.
למה זה חשוב: נותן דרך מקצועית להתייחס לחולשות בספריות ותשתיות.
דוגמה: CVE-2025-XXXX מסמן חולשה ידועה בחבילה.
מה לבדוק / איך למנוע: בודקים אם הפרויקט משתמש בגרסה מושפעת ומה גרסת התיקון.

93GitHub Security וקוד

ציון חומרה לחולשה — CVSS

CVSS = Common Vulnerability Scoring System

מה זה: שיטת ניקוד לחומרת חולשות, בדרך כלל מ-0 עד 10.
למה זה חשוב: עוזר להבין חומרת dependency alert, אך לא מחליף הערכת הקשר עסקי.
דוגמה: CVSS 9.8 נשמע חמור, אבל צריך לבדוק אם החבילה מופעלת במסלול רלוונטי.
מה לבדוק / איך למנוע: משלבים CVSS עם exposure, שימוש בפועל ויכולת תיקון.

94GitHub Security וקוד

רשימת רכיבי תוכנה — SBOM

SBOM = Software Bill of Materials

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

95Production ו-Go Live

סביבת ייצור — Production

Prod = Production Environment

מה זה: הסביבה האמיתית שבה משתמשים אמיתיים עובדים עם האתר.
למה זה חשוב: מה שעובד ב-Preview לא תמיד מוכן ל-Production מבחינת הרשאות, ENV, דומיין ו-Auth URLs.
דוגמה: האתר עלה ל-domain אמיתי ומקבל פניות של לקוחות.
מה לבדוק / איך למנוע: לפני Production עוברים checklist: Auth, Supabase, ENV, headers, טפסים, SEO ודומיין.

96Production ו-Go Live

סביבת בדיקה — Preview / Staging

Preview or Staging Environment

מה זה: סביבה לבדיקה לפני Production.
למה זה חשוב: מקום בטוח להריץ דמו, בדיקות ותיקונים בלי לפגוע במשתמשים אמיתיים.
דוגמה: Vercel Preview או staging subdomain.
מה לבדוק / איך למנוע: מריצים בדיקות על staging ומוודאים שאין דאטה אמיתי או סודות חשופים.

97Production ו-Go Live

בנייה — Build

Build Process

מה זה: תהליך הכנת האפליקציה להרצה: bundling, compiling, optimization.
למה זה חשוב: בעיות ENV או dependencies יכולות להופיע רק בזמן build.
דוגמה: Build נכשל כי חסר Environment Variable בפרודקשן.
מה לבדוק / איך למנוע: בודקים build logs, משתני סביבה ותלויות לפני Go Live.

98Production ו-Go Live

פריסה — Deployment

Deployment

מה זה: העלאת גרסה של האתר לסביבה פעילה.
למה זה חשוב: פריסה היא נקודת סיכון כי שינוי קטן יכול לפתוח בעיה בפרודקשן.
דוגמה: Deploy ל-Vercel אחרי תיקון הרשאות.
מה לבדוק / איך למנוע: מגדירים תהליך מסודר: staging, בדיקות, deploy, smoke test ו-retest.

99Production ו-Go Live

חזרה לגרסה קודמת — Rollback

Rollback

מה זה: החזרת האתר לגרסה קודמת במקרה שגרסה חדשה יצרה תקלה.
למה זה חשוב: חלק חשוב מניהול סיכונים בפרודקשן.
דוגמה: אחרי deploy נשבר Login, חוזרים לגרסה יציבה.
מה לבדוק / איך למנוע: מוודאים שיש יכולת rollback ותיעוד של הגרסה האחרונה התקינה.

100Production ו-Go Live

לוגים — Logs

Logs

מה זה: רישומים של אירועים, שגיאות, בקשות ופעולות במערכת.
למה זה חשוב: עוזרים להבין תקלות, ניסיונות גישה ובעיות אחרי השקה.
דוגמה: לוג של 403 repeated על Admin route.
מה לבדוק / איך למנוע: שומרים לוגים שימושיים בלי לחשוף secrets או מידע אישי מיותר.

101Production ו-Go Live

ניטור — Monitoring

Monitoring

מה זה: מעקב אחרי זמינות, ביצועים, שגיאות ואירועים חריגים.
למה זה חשוב: אחרי Go Live צריך לדעת אם טפסים נשברים, login נכשל או יש שגיאות רבות.
דוגמה: התראה על עלייה בשגיאות 500 אחרי deploy.
מה לבדוק / איך למנוע: מגדירים error tracking, uptime monitoring והתראות בסיסיות.

102Production ו-Go Live

התראות — Alerting

Alerting

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

103Production ו-Go Live

חומת אש לאפליקציות WAF

WAF = Web Application Firewall

מה זה: שכבת הגנה לפני האתר שיכולה לחסום בקשות חשודות או דפוסי תקיפה נפוצים.
למה זה חשוב: מושג חשוב, אבל לא תחליף לתיקון הרשאות וקוד.
דוגמה: WAF עשוי לחסום בקשות אוטומטיות חשודות.
מה לבדוק / איך למנוע: להכיר כשכבת הגנה נוספת; לא לסמוך עליו במקום RLS/AuthZ נכון.

104Production ו-Go Live

מערכת שמות דומיין — DNS

DNS = Domain Name System

מה זה: המערכת שמחברת דומיין לשרת/שירות כמו Vercel.
למה זה חשוב: הגדרות DNS שגויות יכולות לשבור אתר, HTTPS, אימיילים או subdomains.
דוגמה: A/CNAME שמפנה דומיין ל-Vercel.
מה לבדוק / איך למנוע: בודקים רשומות DNS, דומיין, SSL ו-redirects כחלק מ-Go Live.

105Production ו-Go Live

תקשורת מוצפנת — HTTPS / TLS

TLS = Hypertext Transfer Protocol Secure / Transport Layer Security

מה זה: הצפנת התקשורת בין הדפדפן לאתר.
למה זה חשוב: בסיס חובה לכל אתר עם Login, טפסים או מידע אישי.
דוגמה: אתר Production חייב להיפתח עם https:// ולא http://.
מה לבדוק / איך למנוע: בודקים שה-HTTPS פעיל, התעודה תקינה ואין mixed content.

106Production ו-Go Live

תעודת SSL/TLS — SSL Certificate

SSL = Secure Sockets Layer Certificate

מה זה: תעודה שמאפשרת לדפדפן לאמת את האתר ולהצפין תעבורה.
למה זה חשוב: למרות שהמונח SSL ישן, משתמשים בו עדיין בשפה יומיומית.
דוגמה: Vercel מנפיק תעודת TLS לדומיין.
מה לבדוק / איך למנוע: בודקים תוקף תעודה, התאמה לדומיין וחידוש אוטומטי.

107Production ו-Go Live

רשת הפצת תוכן — CDN

CDN = Content Delivery Network

מה זה: שירות שמפיץ תוכן דרך שרתים קרובים למשתמשים ולעיתים מוסיף שכבות אבטחה.
למה זה חשוב: משפיע על ביצועים, caching ולעיתים headers/security.
דוגמה: Vercel/Cloudflare מפיצים assets דרך CDN.
מה לבדוק / איך למנוע: בודקים cache, headers, redirects והאם מידע פרטי לא נשמר ב-cache ציבורי.

108Security Headers

כותרות אבטחה — Security Headers

Security Headers

מה זה: Headers שהשרת שולח לדפדפן כדי להקשיח התנהגות ולהפחית סיכונים.
למה זה חשוב: בדיקה מהירה שנותנת ערך, אבל לא מחליפה הרשאות ו-RLS.
דוגמה: CSP, HSTS, Referrer-Policy, Permissions-Policy.
מה לבדוק / איך למנוע: בודקים עם SecurityHeaders/Observatory ומחליטים מה רלוונטי לאתר.

109Security Headers

מדיניות אבטחת תוכן — CSP

CSP = Content Security Policy

מה זה: Header שמגדיר מאילו מקורות מותר לטעון scripts, styles, images ועוד.
למה זה חשוב: יכול לצמצם XSS וטעינת קוד ממקורות לא רצויים.
דוגמה: CSP מגביל scripts לדומיין האתר ולשירותים מאושרים.
מה לבדוק / איך למנוע: מתחילים בזהירות, בודקים report-only אם צריך, ולא שוברים פונקציונליות.

110Security Headers

הכרחת HTTPS — HSTS

HSTS = HTTP Strict Transport Security

מה זה: Header שמורה לדפדפן להשתמש תמיד ב-HTTPS לאתר.
למה זה חשוב: מחזק את ההגנה אחרי ש-HTTPS מוגדר תקין.
דוגמה: Strict-Transport-Security פעיל בדומיין Production.
מה לבדוק / איך למנוע: מפעילים רק אחרי שה-HTTPS עובד יציב בכל הדומיין וה-subdomains הרלוונטיים.

111Security Headers

מדיניות — Referrer-Policy

Referrer-Policy

מה זה: Header שמגדיר כמה מידע על העמוד הקודם נשלח לאתרים אחרים.
למה זה חשוב: יכול למנוע דליפת URLs פנימיים או פרמטרים רגישים.
דוגמה: מעבר מדף פרטי לאתר חיצוני לא צריך לחשוף URL רגיש מלא.
מה לבדוק / איך למנוע: מגדירים מדיניות שמאזנת פרטיות וצרכי אנליטיקה.

112Security Headers

מדיניות הרשאות דפדפן — Permissions-Policy

Permissions-Policy

מה זה: Header שמגביל שימוש ביכולות דפדפן כמו מצלמה, מיקרופון, מיקום וחיישנים.
למה זה חשוב: מקטין הרשאות שאינן נדרשות לאתר.
דוגמה: אתר שלא צריך מצלמה חוסם camera/microphone.
מה לבדוק / איך למנוע: מגדירים רק יכולות נחוצות ומבטלים את השאר.

113Security Headers

מניעת הטמעה במסגרת — X-Frame-Options / frame-ancestors

X-Frame-Options / CSP frame-ancestors

מה זה: מנגנון שמגביל הטמעת האתר בתוך iframe באתרים אחרים.
למה זה חשוב: יכול לצמצם סיכוני clickjacking.
דוגמה: Admin panel לא אמור להיטען בתוך iframe של אתר אחר.
מה לבדוק / איך למנוע: מגדירים frame-ancestors ב-CSP או X-Frame-Options לפי הצורך.

114Security Headers

הגדרת SameSite לעוגיות — SameSite Cookie

SameSite Cookie Attribute

מה זה: מאפיין Cookie שמגביל שליחת Cookies בין אתרים.
למה זה חשוב: עוזר לצמצם CSRF במערכות מבוססות Cookies.
דוגמה: SameSite=Lax או Strict לפי הצורך.
מה לבדוק / איך למנוע: בודקים שהגדרת SameSite מתאימה לזרימות login, auth callbacks ושירותים חיצוניים.

115Security Headers

עוגייה חסומה ל-JavaScript — HttpOnly Cookie

HttpOnly Cookie Attribute

מה זה: מאפיין שמונע מ-JavaScript בדפדפן לקרוא Cookie.
למה זה חשוב: מקטין סיכון אם יש XSS, כי JS לא יכול לקרוא את ה-session cookie.
דוגמה: session cookie מסומן HttpOnly.
מה לבדוק / איך למנוע: בודקים Cookies רגישים ומעדיפים HttpOnly כשהארכיטקטורה מאפשרת.

116Security Headers

עוגייה מאובטחת — Secure Cookie

Secure Cookie Attribute

מה זה: מאפיין שמאפשר שליחת Cookie רק דרך HTTPS.
למה זה חשוב: חשוב לכל Cookie רגיש בפרודקשן.
דוגמה: session cookie עם Secure=true.
מה לבדוק / איך למנוע: בודקים בפרודקשן שכל Cookies רגישים נשלחים רק ב-HTTPS.

117Security Headers

מדיניות Cache — Cache-Control

Cache-Control

מה זה: Header שקובע איך דפדפן/CDN שומרים תוכן.
למה זה חשוב: Cache לא נכון יכול לשמור מידע פרטי במקום ציבורי או משותף.
דוגמה: Dashboard פרטי לא אמור להיות cache ציבורי.
מה לבדוק / איך למנוע: מגדירים no-store/private לעמודים פרטיים ו-cache מבוקר ל-assets ציבוריים.

118דוחות ושירות ללקוח

ממצא — Finding

Security Finding

מה זה: בעיה, חולשה, הגדרה חסרה או סיכון שנמצא במהלך בדיקה.
למה זה חשוב: הממצא הוא יחידת העבודה בדוח ללקוח.
דוגמה: “משתמש רגיל יכול לראות בקשות של משתמש אחר”.
מה לבדוק / איך למנוע: לכל ממצא כותבים כותרת, חומרה, מה נמצא, הוכחה, סיכון והמלצת תיקון.

119דוחות ושירות ללקוח

הוכחה — Evidence

Evidence

מה זה: תיעוד שמראה שהממצא אמיתי.
למה זה חשוב: עוזר ללקוח להבין ולמפתח לשחזר ולתקן.
דוגמה: צילום מסך, URL, תיאור צעדים, Response מצונזר.
מה לבדוק / איך למנוע: מתעדים בלי לחשוף מידע רגיש אמיתי; משתמשים בדאטה דמו/מצונזר.

120דוחות ושירות ללקוח

תיקון מומלץ — Remediation

Remediation

מה זה: הפעולה המומלצת כדי לתקן את שורש הבעיה.
למה זה חשוב: מבדיל בין “מצאתי בעיה” לבין “יש תוכנית פעולה”.
דוגמה: להוסיף RLS policy שמחזירה רק rows של המשתמש המחובר.
מה לבדוק / איך למנוע: כותבים תיקון ברור, מעשי, לפי עדיפות, בלי להתחייב לתיקון מלא אם זה מחוץ להיקף.

121דוחות ושירות ללקוח

הפחתת סיכון — Mitigation

Mitigation

מה זה: פעולה שמקטינה סיכון גם אם לא מתקנת את שורש הבעיה לגמרי.
למה זה חשוב: שימושי כשאין זמן לתיקון מלא לפני השקה.
דוגמה: חסימת עמוד זמנית עד להשלמת תיקון הרשאות.
מה לבדוק / איך למנוע: מציינים בדוח אם מדובר במענה זמני ולא תיקון סופי.

122דוחות ושירות ללקוח

בדיקה חוזרת — Retest

Retest

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

123דוחות ושירות ללקוח

היקף בדיקה — Scope

Scope

מה זה: מה נכלל בבדיקה: דומיינים, עמודים, משתמשים, מערכות, כלים ורמות עומק.
למה זה חשוב: מונע אי הבנות מול לקוח ומגדיר גבולות אחריות.
דוגמה: נבדקו האתר הראשי, Login, Dashboard, Supabase ו-Storage; לא נבדקו תשלומים.
מה לבדוק / איך למנוע: מגדירים Scope בכתב לפני תחילת בדיקה.

124דוחות ושירות ללקוח

מחוץ להיקף — Out of Scope

Out of Scope

מה זה: מה לא נכלל בבדיקה.
למה זה חשוב: חשוב במיוחד כדי לא ליצור ציפייה לפנטסט מלא או תיקונים כלולים.
דוגמה: לא נבדקו עומסים, תשתיות ענן עמוקות, קוד מלא או compliance רגולטורי.
מה לבדוק / איך למנוע: כותבים Out of Scope בדוח ובהצעת המחיר.

125דוחות ושירות ללקוח

דיווח אחראי — Responsible Disclosure

Responsible Disclosure

מה זה: דרך אתית לדווח על חולשה לבעל המערכת בלי לפרסם או לנצל אותה לרעה.
למה זה חשוב: חשוב אם תלמיד מוצא בעיה אצל לקוח או צד שלישי.
דוגמה: שולחים לבעל האתר תיאור מסודר וממתינים לתגובה במקום לפרסם בפומבי.
מה לבדוק / איך למנוע: בודקים רק עם אישור; אם נמצאה בעיה לא צפויה, עוצרים ומדווחים בצורה אחראית.

126דוחות ושירות ללקוח

הסכם רמת שירות — SLA

SLA = Service Level Agreement

מה זה: הגדרת זמני יעד לטיפול או תגובה לפי חומרה.
למה זה חשוב: עוזר ללקוח להבין מה דחוף ומה יכול לחכות.
דוגמה: Critical לטיפול מיידי, High תוך ימים, Medium בהמשך sprint.
מה לבדוק / איך למנוע: משתמשים ב-SLA כהמלצה או כחלק מהסכם שירות, לא כהבטחה בלי תיאום.

127דוחות ושירות ללקוח

קבלת סיכון — Risk Acceptance

Risk Acceptance

מה זה: החלטה מודעת של הלקוח לקבל סיכון מסוים במקום לתקן אותו מיד.
למה זה חשוב: לא כל ממצא יתוקן מיד, אבל ההחלטה צריכה להיות מודעת ומתועדת.
דוגמה: לקוח מחליט לדחות תיקון Low עד לגרסה הבאה.
מה לבדוק / איך למנוע: מתעדים מי אישר, מה הסיכון, ולמה נדחה.

128דוחות ושירות ללקוח

תקציר מנהלים — Executive Summary

Executive Summary

מה זה: סיכום קצר בשפה עסקית של מצב האבטחה, הסיכונים והצעדים הבאים.
למה זה חשוב: לקוח לא טכני צריך להבין את התמונה בלי לקרוא כל ממצא טכני.
דוגמה: “נמצאה בעיית הרשאות חמורה אחת שמומלץ לתקן לפני השקה”.
מה לבדוק / איך למנוע: כותבים קצר, ברור, ללא הפחדות וללא הבטחות “מאובטח 100%”.

129דוחות ושירות ללקוח

פרטים טכניים — Technical Details

Technical Details

מה זה: החלק בדוח שמיועד למפתח/מבצע תיקון ומסביר איך לשחזר ומה לתקן.
למה זה חשוב: מאפשר להפוך ממצא לתיקון בפועל.
דוגמה: URL, role שנבדק, תוצאה צפויה מול תוצאה בפועל, המלצת תיקון.
מה לבדוק / איך למנוע: כוללים מספיק מידע לתיקון, אבל מצנזרים סודות ונתונים אמיתיים.

130מושגי יסוד

פרוטוקול הקשר למודל — MCP

MCP = Model Context Protocol

מה זה: פרוטוקול פתוח שמאפשר למודל AI (כמו Claude) להתחבר לכלים, מקורות מידע ושירותים חיצוניים בצורה מתוקננת, במקום אינטגרציה ייעודית לכל כלי.
למה זה חשוב: ככל שיותר אתרי Lovable ו-Claude Code מחברים MCP servers (Supabase, GitHub, אימייל ועוד), כל server כזה הוא נקודת גישה נוספת שדורשת בדיקת הרשאות ואמון.
דוגמה: Claude Code מתחבר ל-MCP server של Supabase כדי להריץ שאילתות ישירות על בסיס הנתונים של הפרויקט.
מה לבדוק / איך למנוע: ממפים אילו MCP servers מחוברים, אילו הרשאות יש לכל אחד, והאם מודל ה-AI יכול לבצע פעולות רגישות בלי אישור מפורש.

131מושגי יסוד

פיתוח מונחה AI — Vibe Coding

Vibe Coding

מה זה: שיטת פיתוח שבה המפתח מתאר בשפה טבעית מה הוא רוצה, וכלי AI כמו Lovable, Claude Code או Cursor מייצרים את מרבית הקוד בפועל.
למה זה חשוב: כשה-AI כותב את רוב הקוד, קל להחמיץ בדיקות הרשאה, ניהול סודות ו-RLS — בדיוק הפערים שהמילון הזה עוסק בהם.
דוגמה: בונה אתר מתאר "מערכת ניהול לקוחות עם התחברות" ל-Lovable, שמייצרת טבלאות, טפסים ו-API תוך דקות.
מה לבדוק / איך למנוע: מתייחסים לכל קוד שנוצר על ידי AI כאילו נכתב על ידי מפתח זוטר: קוראים, בודקים הרשאות, ולא מניחים שהוא מאובטח כברירת מחדל.

132חולשות וסיכוני OWASP

הזיית חבילות AI — Slopsquatting

Slopsquatting = AI Package Hallucination Squatting

מה זה: מצב שבו מודל AI "ממציא" שם חבילת קוד (npm/PyPI) שלא קיימת באמת, ותוקפים מזהים את הדפוס ונרשמים לשם הזה מראש עם קוד זדוני.
למה זה חשוב: כלי Vibe Coding מייצרים import/install commands מהר, ולפעמים בלי שהמפתח בודק שהחבילה אכן קיימת ואמינה.
דוגמה: Claude מציע להתקין ספריית "react-secure-forms" שלא קיימת בפועל; תוקף כבר רשם את השם הזה ב-npm עם קוד זדוני.
מה לבדוק / איך למנוע: לפני התקנת חבילה שה-AI המליץ עליה, מוודאים שהיא קיימת במאגר הרשמי, עם היסטוריה, downloads ותחזוקה אמיתית.

133בקרת גישה והרשאות

שיוך המוני — Mass Assignment

Mass Assignment

מה זה: חולשה שבה טופס או API מקבלים אובייקט שלם מהלקוח וכותבים אותו ישירות לטבלה, כולל שדות שהמשתמש לא אמור להיות מסוגל לשנות.
למה זה חשוב: נפוץ מאוד באתרי Lovable/Supabase שבהם טופס נקשר ישירות לעמודות ב-DB בלי סינון שדות מפורש.
דוגמה: טופס עדכון פרופיל שולח גם role: "admin" בבקשה, וה-API מעדכן את זה כי הוא כותב את כל האובייקט שהתקבל בלי סינון.
מה לבדוק / איך למנוע: מוודאים שה-API/Edge Function מעדכן רק רשימת שדות מפורשת ומותרת, ולא שומר את כל מה שהלקוח שלח.

134Supabase, Lovable ונתונים

התחברות דרך צד שלישי — OAuth 2.0

OAuth 2.0

מה זה: פרוטוקול סטנדרטי שמאפשר למשתמש להתחבר לאתר דרך חשבון קיים (Google, GitHub וכו׳) בלי לשתף סיסמה.
למה זה חשוב: אתרי Lovable רבים משתמשים ב-Supabase Auth עם OAuth providers, וטעות ב-redirect URLs או scopes יכולה לחשוף מידע או לאפשר התחזות.
דוגמה: משתמש לוחץ "התחבר עם Google" ומאשר לאתר גישה לפי ה-scopes שהוגדרו לו מראש.
מה לבדוק / איך למנוע: בודקים ש-redirect URLs מוגבלים לדומיינים אמיתיים, וש-scopes המבוקשים הם המינימום הנדרש.

135מושגי יסוד

AI פועל באופן עצמאי — Agentic AI

Agentic AI / AI Agent

מה זה: מערכת AI שיכולה לתכנן ולבצע רצף פעולות בעצמה (לא רק לענות על שאלה), כולל קריאה לכלים חיצוניים.
למה זה חשוב: ככל שסוכן AI מקבל יותר עצמאות (למשל דרך MCP), כך גדל הצורך לוודא שיש לו רק את ההרשאות המינימליות הנדרשות.
דוגמה: Claude Code רץ כ-agent בטרמינל, יכול לקרוא קבצים, להריץ פקודות ולבצע commit בעצמו.
מה לבדוק / איך למנוע: בודקים אילו פעולות הסוכן מורשה לבצע ללא אישור אנושי, ומגבילים לפי עיקרון ההרשאה המינימלית.

136מושגי יסוד

קריאה לכלים — Tool Use / Function Calling

Tool Use / Function Calling

מה זה: היכולת של מודל AI לבחור ולהפעיל פונקציה או כלי חיצוני (API, חיפוש, DB) כדי להשלים משימה.
למה זה חשוב: כל כלי שמודל AI יכול לקרוא לו הוא בעצם הרשאה — חשוב לדעת אילו כלים חשופים למודל ומה הם מסוגלים לעשות.
דוגמה: מודל AI מזהה שצריך לחפש מידע עדכני ובוחר לקרוא לכלי web_search במקום לענות ממידע ישן.
מה לבדוק / איך למנוע: רושמים רשימת כלים שחשופים לכל agent/מודל, ומוודאים שאין כלי עם הרשאות רחבות מדי לצורך המשימה.

137חולשות וסיכוני OWASP

תקיפת שרשרת אספקה — Supply Chain Attack

Supply Chain Attack

מה זה: תקיפה שמכוונת לא לאתר עצמו אלא לרכיב שהוא תלוי בו — ספרייה, כלי build, MCP server או שירות חיצוני.
למה זה חשוב: אתר יכול להיות כתוב מצוין, אבל עדיין להיפרץ דרך תלות שנפגעה בלי קשר לקוד שלך.
דוגמה: עדכון שגרתי של ספריית npm פופולרית מכיל קוד זדוני שמדליף secrets מכל פרויקט שמשתמש בה.
מה לבדוק / איך למנוע: עוקבים אחרי Dependabot/advisories, לא מעדכנים dependencies אוטומטית בלי בדיקה, ומגבילים הרשאות ל-CI/CD ול-MCP servers חיצוניים.

138Security Headers

חטיפת קליק — Clickjacking

Clickjacking

מה זה: התקפה שבה אתר זדוני טוען את האתר שלך בתוך iframe שקוף ומטעה משתמש ללחוץ על פעולה בלי לדעת.
למה זה חשוב: רלוונטי בעיקר לעמודי ניהול או פעולות רגישות (מחיקה, אישור, תשלום) שיכולות להתבצע בלחיצה אחת.
דוגמה: משתמש חושב שהוא לוחץ על כפתור משחק, אבל בפועל הוא לוחץ על כפתור "מחק חשבון" של אתר אחר שטעון מתחתיו בשקיפות.
מה לבדוק / איך למנוע: מוודאים שיש frame-ancestors מתאים ב-CSP או X-Frame-Options, במיוחד בעמודי אדמין ופעולות הרסניות.

139Security Headers

שלמות משאבים — SRI

SRI = Subresource Integrity

מה זה: מנגנון שמאפשר לדפדפן לוודא שקובץ JS/CSS שנטען מ-CDN חיצוני לא שונה מהגרסה שציפית לה.
למה זה חשוב: אם CDN חיצוני נפרץ, SRI מונע מהדפדפן להריץ קוד ששונה בלי ידיעתך.
דוגמה: תג script טוען ספריית JS מ-CDN עם attribute integrity שמכיל hash של הקובץ המקורי.
מה לבדוק / איך למנוע: לכל script/style שנטען ממקור חיצוני, בודקים אם אפשר וכדאי להוסיף integrity ו-crossorigin.

140מושגי יסוד

אחזור מועשר בייצור — RAG

RAG = Retrieval-Augmented Generation

מה זה: טכניקה שבה מודל AI מביא מידע רלוונטי ממקור חיצוני (מסמכים, DB) לפני שהוא מנסח תשובה, במקום להסתמך רק על מה שלמד באימון.
למה זה חשוב: אם המקור שממנו שולפים מידע לא מסונן לפי הרשאות משתמש, ה-AI עלול "להדליף" מידע שהמשתמש לא אמור לראות.
דוגמה: צ׳אטבוט תמיכה שמביא תשובות ממאגר מסמכים פנימי, אבל לא בודק שהמשתמש מורשה לראות את המסמך הספציפי שנשלף.
מה לבדוק / איך למנוע: מוודאים שהאחזור (retrieval) מכבד את אותם כללי הרשאה כמו כל שאילתה רגילה למקור המידע.

141מושגי יסוד

חלון הקשר — Context Window

Context Window

מה זה: כמות הטקסט (בטוקנים) שמודל AI יכול "לראות" בבת אחת בשיחה או במשימה נתונה.
למה זה חשוב: כשסוכן AI עובד על קוד גדול, חלון הקשר מוגבל אומר שהוא עלול לפספס חלקים רלוונטיים לאבטחה שנמצאים מחוץ למה שהוא רואה כרגע.
דוגמה: Claude Code מתבקש לתקן קובץ אחד, אבל לא רואה בו-זמנית קובץ הרשאות אחר שתלוי בשינוי הזה.
מה לבדוק / איך למנוע: בבקשות משמעותיות, מציינים לסוכן במפורש אילו קבצים/הקשר קשורים, ולא מסתמכים על שהוא "יזכור" הכל.