אבטחת מידע באפליקציות: איך עוברים מבדק חדירות כבר בפעם הראשונה

בקצרה: אפליקציה עוברת מבדק חדירות בפעם הראשונה כשהאבטחה היא חלק מהדרך שבה כותבים את הקוד. כסו את OWASP Top 10 (במהדורת 2025 בקרת גישה פגומה נמצאת במקום הראשון), סרקו תלויות בכל Pull Request, שמרו סודות ב-Vault, אמתו כל קלט בצד השרת, ובמובייל השתמשו באחסון המאובטח של הפלטפורמה. אבטחה שנבנית מההתחלה עולה הרבה פחות מתיקונים אחרי מבדק החדירות.

הרבה אפליקציות נכשלות במבדק החדירות הראשון

ראינו את זה עשרות פעמים. חברה בונה אפליקציה חצי שנה, שוכרת חברה למבדקי חדירות, ומקבלת דוח של 40 עמודים עם פרצות שמחייבות שינויים בארכיטקטורה. התיקונים אוכלים עוד 2 עד 3 חודשי פיתוח, כי את האבטחה הדביקו בסוף, במקום לבנות אותה מההתחלה.

הדרך האחרת פשוטה: בונים את האבטחה לתוך תהליך הפיתוח מהיום הראשון. היא לא נדחית לשלב נפרד בסוף. היא חלק מכל ספרינט ומכל שורת קוד.

OWASP Top 10: מה תוקפים מנצלים בפועל

הארגון OWASP (Open Web Application Security Project) מפרסם רשימה של עשרת הסיכונים הקריטיים ביותר באפליקציות Web. המהדורה העדכנית היא OWASP Top 10:2025. רוב המתקפות המוצלחות מנצלות את הבעיות המוכרות האלה, ולכן מי שמטפל בהן סוגר חלק גדול מהסיכון.

בקרת גישה פגומה (Broken Access Control) נמצאת במקום הראשון ברשימת 2025, כמו ב-2021. משתמשים מגיעים לנתונים או לפעולות שאין להם הרשאה אליהם, כי ה-Endpoint לא בודק הרשאות. אכפו הרשאות בצד השרת בכל בקשה, וקבעו חסימה כברירת מחדל.

הזרקות (Injection) ירדו למקום החמישי ב-2025, אחרי שהיו במקום השלישי ב-2021. הזרקת SQL, הזרקת NoSQL, הזרקת פקודות. הפתרון: אף פעם לא לשרשר קלט של משתמש לתוך שאילתה. השתמשו בשאילתות עם פרמטרים וב-ORM. תמיד, בלי יוצאים מן הכלל. גם לא בכלי ניהול, וגם לא ב-API פנימי.

כשלי הזדהות (Authentication Failures) נמצאים במקום השביעי ב-2025, ובעבר נקראו Broken Authentication. הכוונה לטוקנים של סשן שאפשר לנחש, סיסמאות שנשמרות כטקסט גלוי, או מסכי התחברות בלי הגבלה על מספר הניסיונות. השתמשו בספריות הזדהות מוכרות (Clerk,‏ Auth0,‏ Firebase Auth), ואל תבנו לבד. בכל מערכת הזדהות שנבנתה בהתאמה אישית ועברה אצלנו סקר, מצאנו לפחות פרצה קריטית אחת.

כשלים קריפטוגרפיים (Cryptographic Failures), במקום הרביעי ב-2025, נקראו עד 2021 Sensitive Data Exposure. הם קורים כשמידע עובר בלי הצפנה, נשמר בלוגים, או נגיש דרך Endpoints שלא בודקים הרשאות כמו שצריך. הצפינו את המידע באחסון ובתעבורה, ובדקו הרשאות בכל Endpoint.

שיטות אבטחה שעובדות

בזמן הפיתוח

סריקת תלויות. הריצו Dependabot,‏ Snyk או npm audit על כל Pull Request. ספריות ישנות עם CVE ידועים הן הדרך הקלה ביותר לתקוף. ב-8 מתוך 10 סקרי הקוד האחרונים שעשינו מצאנו תלויות עם פרצות קריטיות, שאפשר לנצל עם סקריפטים שזמינים לכל אחד ברשת. ברשימת 2025 נכנסו כשלים בשרשרת האספקה של התוכנה (Software Supply Chain Failures) למקום השלישי, ולכן בדיקת תלויות צריכה לרוץ בכל Pipeline.

ניהול סודות. אין סודות בקוד. אף פעם. לא בקובצי סביבה שנכנסו ל-git, לא בתוך Docker Images ולא בהודעות Slack. השתמשו ב-Vault: HashiCorp Vault,‏ AWS Secrets Manager או Azure Key Vault. החליפו את הסודות כל רבעון.

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

בסקירת הקוד

צ׳קליסט אבטחה בכל סקירה. בכל Pull Request בודקים: כל הקלט מאומת בצד השרת? כל השאילתות למסד הנתונים עם פרמטרים? יש בדיקת הרשאות בכל Endpoint? השגיאות מטופלות בלי לחשוף פרטים פנימיים?

Linting אבטחה אוטומטי. כלים כמו Semgrep ו-SonarQube מזהים בקוד דפוסים מוכרים של בעיות אבטחה. הריצו אותם ב-CI, לצד ה-Linter הרגיל.

בפריסה

HTTPS בכל מקום. בלי יוצאים מן הכלל. גם בסביבות הפיתוח, כי המפתחים צריכים לבדוק את מנגנוני האבטחה בדיוק כמו שהם יעבדו ב-Production.

כותרות Content Security Policy. CSP מונע מתקפות XSS, כי הוא אומר לדפדפן מאילו מקורות מותר לטעון תוכן. CSP קפדני הוא מאמצעי האבטחה היעילים ביותר, וההטמעה שלו לא עולה כלום.

הגבלת קצב בכל Endpoint. מסך ההתחברות הוא רק ההתחלה. לכל Endpoint ב-API צריכה להיות הגבלת קצב. בלעדיה תוקפים יכולים לנחש בכוח כל דבר, מאיפוס סיסמאות ועד קודי קופון.

אבטחה במובייל

לאפליקציות מובייל יש עוד חזיתות תקיפה.

Certificate Pinning מונע מתקפות Man-in-the-Middle, כי האפליקציה מדברת רק עם השרתים שלכם. הטמיעו אותו, ועדכנו את ה-Pins לפני שהתעודות פגות.

אחסון מאובטח. אל תשמרו טוקנים ב-UserDefaults או ב-SharedPreferences. השתמשו ב-Keychain של iOS או ב-Keystore של Android. הם נותנים הצפנה מבוססת חומרה, שמחזיקה גם במכשיר שעבר Root.

ערפול קוד (Obfuscation). אפשר לפרק אפליקציית מובייל בחזרה לקוד. ערפלו את הקוד (ProGuard ב-Android, ההגנות המובנות של Swift ב-iOS), ואף פעם אל תכניסו מפתחות API או סודות לקובץ האפליקציה.

מהעבודה שלנו

Check2Fly, מערכת הגבולות של ישראל בתקופת הקורונה, הייתה אחת המערכות הציבוריות המותקפות ביותר בארץ בזמן המגפה. האבטחה הייתה חלק מכל ספרינט מהיום הראשון: הצפנה מקצה לקצה, תשתית מוקשחת וניטור רציף. המערכת עברה את ביקורות האבטחה של הממשלה לפני ההשקה, וטיפלה במיליוני רשומות בריאות רגישות בלי אף אירוע אבטחה. ללקוח מתחום הביטחון בנינו צ׳אט AI פנימי שה-CISO אישר בפגישה אחת, עם רשת פרטית, Pipeline אבטחה של שבע שכבות, ובלי אף פרט הזדהות ששמור במערכת.

שאלות נפוצות

כמה אבטחת מידע מוסיפה לעלות הפיתוח? כ-10% עד 15% כשבונים אותה מההתחלה. כ-30% עד 40% כשמוסיפים אותה אחרי הפיתוח. החשבון פשוט.

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

אילו הסמכות צריכות להיות לבית התוכנה שעובד איתנו? ISO 27001 מעיד על נהלי אבטחה ברמת הארגון. SOC 2 Type II מראה בקרות שנבדקו לאורך זמן. בתחומים מסוימים בדקו גם ידע ברגולציה הרלוונטית: PCI לתשלומים, HIPAA לבריאות.

בונים אפליקציה שאבטחת המידע בה קריטית? דברו עם הצוות שלנו על פיתוח שמתחיל מאבטחה.