מה זה OWASP Top 10?
OWASP (Open Web Application Security Project) היא ארגון ללא מטרת רווח המספק أدوات, מסמכים וידע בתחום אבטחת יישומים באינטרנט. רשימת ה־Top 10 היא סקירה שנתית של עשרת הפערים האבטחתיים הנפוצים והמסוכנים ביותר באפליקציות ווב.
הרשימה אינה תקנית, אלא מבוססת על נתונים אמפיריים מאלפי ארגונים ברחבי העולם — כולל ניתוחי אבטחה, סקרי פריצה ונתוני תקיפות אמיתיות. גרסה עדכנית (2021) מתעדכנת כל 3–4 שנים, עם עדכונים רגילים בין הגרסאות.
1. שיבוש זיהוי וניהול סשן (Broken Access Control)
הבעיה: חוסר הגבלות ברורות על מה משתמש מורשה לראות או לעשות. למשל: גישה לנתוני משתמש אחר דרך שינוי מזהה URL (/user?id=123 → /user?id=124).
הפתרון: לא להסתמך על "הסתרה", אלא על בדיקת הרשאות בכל קריאה לשרת — גם אם המשתמש ניגש ישירות ל-API.
// ❌ לא בטוח: סמך על נתוני לקוח
const userId = req.query.id;
// ✅ בטוח: בדוק הרשאות מול הסשן הנוכחי
if (!canAccessUser(req.session.userId, userId)) {
throw new Error("אין הרשאה");
}role, isAdmin או accessLevel שנשלחים מהלקוח. תמיד לבדוק את ההרשאות מול בסיס הנתונים/הסשן.
2. внедור קבצים מסוכנים (Injection)
הבעיה: הזנה של פקודות לא ממוינות לתוך שאילתות, פקודות מערכת או פקודות SQL — למשל: ' OR '1'='1 בשדה התחברות.
הפתרון: שימוש באופציה המומלצת בכל שפה — פרמטריזציה (Parameterized Queries) או ORM עם הגנות מובנות.
-- ❌ מסוכן: בניית שאילתה דינמית
SELECT * FROM users WHERE email = '" + userInput + "';
-- ✅ בטוח: שאילתה פרמטרית
SELECT * FROM users WHERE email = ?;# ✅ דוגמה ב-Python עם sqlite3
cursor.execute("SELECT * FROM users WHERE email = ?", (email_input,))3. חוסר אימות ותוקף של נתונים (Security Misconfiguration)
הבעיה: הגדרות ברירת מחדל מסוכנות, הודעות שגיאה מפורטות מדי (שחשפות מבנה המערכת), או שירותים מיותרים פעילים (כמו דפדפן קבצים, מסכים פנימיים, או ממשק ניהול לא מאובטח).
הפתרון: סקר אוטומטי של קונפיגורציה, הסרת כל שירות שאינו חיוני, כיבוי הודעות שגיאה מפורטות בפרודקשן, ושימוש ב־hardening של שרתים ואפליקציות.
# ✅ דוגמה לקונפיגורציה בטוחה ב-Docker
FROM node:18-alpine
USER node # לא כ-root!
EXPOSE 3000
HEALTHCHECK --interval=30s CMD curl -f http://localhost:3000/health || exit 14. ניצול תוכן זר (Insecure Design)
הבעיה: אי שילוב של עקרונות אבטחה בשלב העיצוב — למשל: חוסר תכנון לשמירת סיסמאות, חוסר אימות דו-שלבי, או חוסר טיפול בזרימת נתונים רגישים (PII).
הפתרון: שימוש ב־Threat Modeling בשלב תכנון המוצר, ובמערכת Secure SDLC הכוללת ביקורות אבטחה, בדיקות אוטומטיות, ובדיקות ידניות.
STRIDE
מודל זיהוי סיכונים: Spoofing, Tampering, Repudiation, Info Disclosure, DoS, Elevation of Privilege
Threat Dragon
כלי פתוח ל־Threat Modeling של OWASP
OWASP ASVS
מסמך אישור אבטחה למחזור הפיתוח
השוואה: פגיעויות לפי השפעה וסיכון
הטבלה הבאה מציגה את 5 הפגיעויות הראשונות בגרסה האחרונה של OWASP Top 10 (2021), לפי דרגת נפוץ וסיכון כולל:
| מיקום | שם הפגיעות | סיכון ממוצע | תדירות במבחנים |
|---|---|---|---|
| #1 | Broken Access Control | 9.2 / 10 | 94% מהמערכות |
| #2 | Cryptographic Failures | 8.7 / 10 | 75% מהמערכות |
| #3 | Injection | 8.5 / 10 | 68% מהמערכות |
| #4 | Insecure Design | 7.9 / 10 | 52% מהמערכות |
| #5 | Security Misconfiguration | 7.6 / 10 | 80% מהמערכות |
איך להתחיל היום – רשימת פעולות מיידיות
- הוספת SAST: הוסף כלי כמו ZAP או Semgrep ל־CI/CD שלך
- תגמול אבטחה: צור תהליך פשוט לדווח על פגיעויות (כמו GitHub Security Advisories)
- הכשרה פנימית: ערך 30 דקות שבועי על אחת מהפגיעויות — עם דוגמה קודית ותיקון
- תבניות בטוחות: השתמש בתבניות קוד מוכנות מראש (ex: Next.js with Auth.js, Express with Helmet)
- בדיקה ידנית: נסה לעבור על כל נקודת כניסה (form, API, query param) ולבדוק האם אפשר לעקוף את ההרשאות
# 🛠️ טיפ מהיר: הוספת helmet ל-Express
npm install helmet
// ואז בקוד:
app.use(require("helmet"));✍️ נכתב ע"י יעקב בידני | Senior AI & Full-Stack Expert | bdnhost.net