אבטחת אפליקציות מובייל: 10 בדיקות לפני השקה

**מאת: איתמר מלול, מייסד ומנכ"ל AI BUDDY** # אבטחת אפליקציות מובייל: 10 בדיקות שחייבים לעשות לפני השקה > **על המחבר:** איתמר מלול הוא מייסד ומנכ"ל AI BUDDY, חברה ישראלית המתמחה בסוכני AI ואוטומציה עסקית. עם ניסיון של מעל 10 שנים בהייטק ופיתוח מוצרים, איתמר מוביל צוות המטמיע פתרונות AI בעסקים ישראלים מכל הגדלים. כל שבוע אני רואה את אותו סיפור: סטארטאפ ישראלי משקיע חודשים בפיתוח אפליקציה, דוחף אותה לסטור, ואז מגלה שמישהו שאב את כל הדאטה של המשתמשים דרך API לא מאובטח. זה לא תרחיש תיאורטי. זה קורה. בישראל. בשנת 2026. אבטחת אפליקציות מובייל היא לא משהו שמוסיפים ברגע האחרון כמו תיקון באגים קוסמטיים. זה חלק מהארכיטקטורה, מהתכנון, מהקוד עצמו. ובכל זאת, רוב הצוותים שאני מכיר מדלגים על בדיקות אבטחה בסיסיות כי "אין זמן" או "נטפל בזה אחרי ההשקה". אחרי ההשקה זה מאוחר מדי. במאמר הזה אני מפרט 10 בדיקות אבטחה קונקרטיות שכל אפליקציית מובייל חייבת לעבור לפני שהיא מגיעה למשתמשים. לא תיאוריה, לא המלצות כלליות. צ'קליסט מעשי עם כלים חינמיים שאפשר להתחיל להשתמש בהם היום. ## למה אבטחת אפליקציות מובייל שונה מאבטחת ווב באפליקציית ווב, הקוד רץ על השרת שלכם. יש לכם שליטה. באפליקציית מובייל, הקוד רץ על המכשיר של המשתמש. המכשיר הזה יכול להיות rooted, יכול להריץ proxy שמיירט תעבורה, יכול להיות מחובר לרשת Wi-Fi זדונית. אין לכם שליטה על הסביבה. זה אומר שכל הנחה שעובדת בצד שרת (כמו "התעבורה מוצפנת כי אנחנו משתמשים ב-HTTPS") לא בהכרח נכונה במובייל. תוקף יכול לעקוף certificate pinning, לפרק את ה-APK, לקרוא את הקוד, למצוא מפתחות API שרשומים בקוד. [OWASP Mobile Top 10](https://owasp.org/www-project-mobile-top-10/) מסווג את הסיכונים הנפוצים ביותר. הרשימה העדכנית כוללת אחסון לא מאובטח, תקשורת לא מאובטחת, אימות חלש, ועוד. הצ'קליסט שלי מבוסס על הרשימה הזו, אבל מותאם למציאות של מפתחים ישראליים. ## הצ'קליסט: 10 בדיקות אבטחה לפני השקה ### 1. הצפנת מידע בתנועה (Data in Transit) HTTPS זה לא מספיק. כן, אתם צריכים TLS 1.3 לכל התקשורת. אבל מעבר לזה: האם אתם מאמתים את התעודה של השרת? האם אתם חוסמים תעבורה ל-HTTP רגיל? האם אתם משתמשים ב-certificate pinning? **מה לבדוק:** - כל הבקשות עוברות ב-HTTPS, בלי fallback ל-HTTP - TLS 1.2 מינימום, עדיף TLS 1.3 - אין mixed content (חלק מהמשאבים נטענים ב-HTTP) - Network Security Config (Android) או ATS (iOS) מוגדרים נכון **כלי חינמי:** [OWASP ZAP](https://www.zaproxy.org/) יכול ליירט תעבורה ולזהות בעיות TLS. ### 2. הצפנת מידע במנוחה (Data at Rest) מה קורה כשמישהו מוצא טלפון אבוד? או כשמישהו עם גישה פיזית למכשיר מנסה לשלוף מידע? **מה לבדוק:** - מידע רגיש (טוקנים, נתוני משתמש) מאוחסן ב-Keychain (iOS) או Keystore (Android), לא ב-SharedPreferences או UserDefaults רגילים - בסיס נתונים מקומי (SQLite, Realm) מוצפן - קבצי לוג לא מכילים מידע רגיש - Cache של בקשות רשת לא שומר תשובות עם מידע אישי - Clipboard לא מכיל סיסמאות לאחר העתקה (timeout) טעות נפוצה שאני רואה בהרבה אפליקציות ישראליות: שמירת JWT token ב-AsyncStorage של React Native. AsyncStorage הוא לא מוצפן. כל מי שמחבר את המכשיר למחשב יכול לקרוא את הקובץ. ### 3. אימות ואוטוריזציה (Authentication) OAuth2 הוא הסטנדרט. אם אתם מממשים אימות בעצמכם (שם משתמש וסיסמה ישירות), יש סיכוי גבוה שאתם עושים את זה לא נכון. **מה לבדוק:** - OAuth2 / OpenID Connect מוטמע נכון (עדיף PKCE flow למובייל) - אימות ביומטרי (טביעת אצבע, Face ID) כשכבת הגנה נוספת - הגבלת ניסיונות התחברות (brute force protection) - טוקנים עם תוקף מוגבל (access token קצר, refresh token ארוך יותר) - Logout מבטל את הטוקן גם בצד השרת - Multi-factor authentication לפעולות רגישות (תשלום, שינוי סיסמה) ### 4. אבטחת API ה-API הוא נקודת התורפה הכי גדולה ברוב האפליקציות. זה המקום שבו תוקפים יתמקדו קודם כל, כי הם יכולים לשלוח בקשות ישירות לשרת בלי לעבור דרך ממשק המשתמש. **מה לבדוק:** - Rate limiting על כל endpoint (במיוחד login ו-registration) - Input validation בצד השרת (לא רק בצד הלקוח) - אין information leakage בהודעות שגיאה (לא לחשוף stack traces) - Authorization checks על כל endpoint, לא רק authentication - IDOR protection: משתמש A לא יכול לגשת למידע של משתמש B על ידי שינוי ID בבקשה **כלי חינמי:** [Burp Suite Community Edition](https://portswigger.net/burp/communitydownload) מאפשר ליירט ולשנות בקשות API. ### 5. Certificate Pinning Certificate pinning אומר שהאפליקציה מקבלת רק תעודות SSL ספציפיות, ולא כל תעודה שהמכשיר סומך עליה. בלי pinning, תוקף יכול להתקין תעודה מזויפת על המכשיר וליירט את כל התעבורה. למידע נוסף על [רגולציית AI בישראל ובאירופה](https://vibetech.co.il/article/ai-regulation-israel-eu-2026-developments). **מה לבדוק:** - Certificate pinning מוטמע (OkHttp ב-Android, URLSession ב-iOS, או ספריית TrustKit) - יש מנגנון לעדכון pins בלי שחרור גרסה חדשה (pin rotation) - האפליקציה לא קורסת כשה-pin לא תואם, אלא מציגה הודעה ברורה - בדיקה שה-pinning עובד: השתמשו ב-proxy (mitmproxy, Charles) ותוודאו שהבקשות נחסמות ### 6. הגנה על הקוד (Code Obfuscation) באנדרואיד, כל APK אפשר לפרק ולקרוא את הקוד. ב-iOS קצת יותר קשה, אבל עדיין אפשרי. אם יש לכם לוגיקה עסקית רגישה, מפתחות API, או אלגוריתמים שאתם רוצים להגן עליהם, obfuscation הוא הכרח. **מה לבדוק:** - ProGuard / R8 מופעל באנדרואיד (מינימום) - אין מפתחות API, סיסמאות, או secrets בקוד (hardcoded). השתמשו ב-environment variables או remote config - אין debug logs בגרסת production - String encryption לערכים רגישים - Anti-tampering: האפליקציה מזהה אם הקוד שונה ### 7. בדיקות חדירה (Penetration Testing) זה לא דבר שאפשר לעשות בעצמכם (אם אתם לא מומחי אבטחה). אבל כן אפשר להריץ כלים אוטומטיים שמזהים בעיות נפוצות. **מה לבדוק:** - סריקה אוטומטית עם MobSF (Mobile Security Framework), כלי קוד פתוח שמנתח APK ו-IPA - בדיקה ידנית של ה-API עם Burp Suite או OWASP ZAP - בדיקת root/jailbreak detection: האם האפליקציה מתנהגת אחרת על מכשיר פרוץ? - בדיקת SSL pinning bypass: האם Frida יכול לעקוף את ההגנות? **כלי חינמי:** [MobSF](https://github.com/MobSF/Mobile-Security-Framework-MobSF) עושה ניתוח סטטי ודינמי של אפליקציות מובייל. מעולה כנקודת התחלה. ### 8. אבטחת SDKs של צד שלישי כמה SDKs יש באפליקציה שלכם? ספריית אנליטיקס, SDK של רשת חברתית, ספריית תשלומים, crash reporting. כל אחד מהם הוא קוד שמישהו אחר כתב, ושאתם סומכים עליו עם הנתונים של המשתמשים שלכם. **מה לבדוק:** - בדיקת הרשאות: אילו הרשאות כל SDK דורש? האם הן הגיוניות? - בדיקת תעבורת רשת: לאן SDKs שולחים מידע? (Wireshark או Charles Proxy) - עדכניות: האם אתם משתמשים בגרסאות עדכניות? ספריות ישנות עלולות להכיל פגיעויות ידועות - רישיונות ופרטיות: האם ה-SDK עומד בדרישות GDPR? האם הוא משתף מידע עם צדדים שלישיים? - מינימליזם: הסירו SDKs שאתם לא באמת צריכים בעיה שאני רואה הרבה: אפליקציות ישראליות שמשתמשות ב-Firebase Analytics, Facebook SDK, AppsFlyer, Mixpanel, ועוד 3 ספריות אנליטיקס. כל אחת שולחת מידע על המשתמש לשרתים שונים. חשבו על זה מזווית של פרטיות. ### 9. עמידה בדרישות רגולציה (Privacy Law Compliance) ישראל יש חוק הגנת הפרטיות ותקנות אבטחת מידע. אם יש לכם משתמשים באירופה, אתם חייבים לעמוד גם ב-GDPR. זה לא רק עניין משפטי, זה עניין טכני. **מה לבדוק:** - מדיניות פרטיות ברורה ונגישה מתוך האפליקציה - הסכמה מפורשת (opt-in) לאיסוף מידע שלא נדרש לפעולת האפליקציה - יכולת למשתמש למחוק את המידע שלו (Right to Erasure) - יכולת לייצא מידע אישי (Data Portability) - אם אתם מעבירים מידע לחו"ל (שרתי ענן בארה"ב, למשל), תיעוד של זה במדיניות הפרטיות - רישום מאגר מידע אצל רשם מאגרי המידע (דרישה ישראלית) - חוק הגנת הפרטיות (התשמ"א 1981) דורש אבטחה מתאימה לסוג המידע לצוותים שעובדים עם שוק אירופאי: GDPR דורש Privacy by Design. זה אומר שאבטחה ופרטיות צריכים להיות חלק מהתכנון, לא תוספת. ### 10. תגובה לאירועי אבטחה (Incident Response) מה קורה כשמישהו באמת פורץ? יש לכם תוכנית? **מה לבדוק:** - יש logging מספיק (אבל לא מידע רגיש בלוגים!) כדי לזהות פריצה - יש מנגנון remote kill switch: יכולת לחסום גרסאות פגיעות - יש תוכנית תגובה: מי אחראי, מה הצעדים, איך מודיעים למשתמשים - יש גיבויים ויכולת שחזור - Force update: יכולת לכפות עדכון גרסה אם מתגלה פגיעות קריטית ## כלים חינמיים לבדיקת אבטחה | כלי | מה הוא עושה | מתאים ל | |------|-------------|---------| | [OWASP ZAP](https://www.zaproxy.org/) | סורק פגיעויות ומיירט תעבורה | בדיקת API ותעבורת רשת | | [MobSF](https://github.com/MobSF/Mobile-Security-Framework-MobSF) | ניתוח סטטי ודינמי של APK/IPA | סריקה ראשונית מקיפה | | [Burp Suite Community](https://portswigger.net/burp/communitydownload) | proxy ליירוט ובדיקת בקשות | בדיקת API ידנית | | Frida | framework ל-dynamic instrumentation | בדיקת runtime, bypass של הגנות | | jadx | decompiler ל-Android APK | בדיקת קוד מקור | | objection | runtime exploration למובייל | בדיקת iOS ו-Android | ## פגיעויות נפוצות באפליקציות ישראליות אחרי שנים של עבודה עם חברות טכנולוגיה בישראל, יש כמה דפוסים חוזרים: **אחסון טוקנים לא מאובטח:** הרבה אפליקציות React Native שומרות JWT ב-AsyncStorage. זה קובץ JSON רגיל על המכשיר. הפתרון: react-native-keychain שמשתמש ב-Keychain/Keystore של מערכת ההפעלה. **API ללא rate limiting:** סטארטאפים רבים משיקים עם API "פתוח" בלי הגבלת קצב. תוקף יכול לשלוח אלפי בקשות בשנייה. הפתרון: rate limiting ב-API gateway (nginx, Cloudflare, AWS API Gateway). **מפתחות API בקוד:** Google Maps API key, Firebase config, Stripe publishable key. כל אלה גלויים בקוד. publishable keys זה בסדר, אבל secret keys בקוד זה אסון. הפתרון: environment variables וגישה דרך backend. **חוסר אימות בצד שרת:** אפליקציה שבודקת הרשאות רק בצד הלקוח. אם התוקף שולח בקשה ישירות לשרת, האימות לא קיים. הפתרון: כל בדיקת הרשאה חייבת להיות בצד שרת. ## איך להטמיע את הצ'קליסט בתהליך הפיתוח לא צריך לעצור הכל ולעשות "ספרינט אבטחה". עדיף לשלב את הבדיקות בתהליך הפיתוח הרגיל: **בשלב התכנון:** הגדירו threat model. מה התוקף רוצה להשיג? מידע אישי? גישה לחשבונות? שימוש חינמי בשירות בתשלום? **בשלב הפיתוח:** code review עם פוקוס על אבטחה. השתמשו ב-linters שמזהים בעיות אבטחה (eslint-plugin-security, Semgrep). **לפני השחרור:** הריצו MobSF על ה-build. בדקו עם proxy שה-certificate pinning עובד. ודאו שאין debug logs. **אחרי ההשקה:** מוניטורינג של בקשות חריגות. Bug bounty program אם יש לכם תקציב. עדכונים שוטפים של ספריות. ## שאלות נפוצות (FAQ) ### כמה עולה בדיקת חדירה לאפליקציה? בדיקת חדירה מקצועית בישראל עולה בדרך כלל בין 15,000 ל-50,000 שקל, תלוי בגודל האפליקציה ובהיקף הבדיקה. לסטארטאפים בשלב מוקדם, הכלים החינמיים שציינתי (MobSF, OWASP ZAP) יכולים לכסות 60-70% מהבעיות הנפוצות. ### האם React Native פחות מאובטח מ-native? לא בהכרח, אבל יש אתגרים ספציפיים. הקוד ב-JavaScript bundle קריא יחסית (גם אחרי minification). AsyncStorage לא מוצפן. ספריות כמו react-native-keychain ו-react-native-ssl-pinning פותרות את רוב הבעיות. ### האם GDPR רלוונטי לאפליקציה ישראלית? אם יש לכם משתמשים באירופה, כן. וגם אם אין לכם כרגע, כדאי לבנות את האפליקציה בצורה שתתמוך ב-GDPR. זה חוסך עבודה בהמשך כשתרצו להתרחב. ### מה עדיף, certificate pinning או public key pinning? Public key pinning עדיף כי הוא שורד חידוש תעודות. עם certificate pinning, כל פעם שמחדשים תעודת SSL צריך לשחרר גרסה חדשה של האפליקציה. ### כל כמה זמן צריך לעדכן את בדיקות האבטחה? לפחות פעם ברבעון, או אחרי כל שינוי גדול בארכיטקטורה, הוספת SDK חדש, או שינוי בזרימת האימות. ## סיכום אבטחת אפליקציות מובייל היא לא פרויקט חד פעמי. זה תהליך שמתחיל בשלב התכנון ונמשך כל עוד האפליקציה חיה. הצ'קליסט הזה נותן לכם נקודת התחלה טובה, אבל הוא לא מחליף מומחה אבטחה כשמדובר באפליקציות שמטפלות במידע רגיש (פיננסי, רפואי, וכדומה). התחילו מהדברים הפשוטים: הצפנה נכונה, אימות חזק, API מאובטח. תנו ל-MobSF לסרוק את ה-build שלכם. תתפלאו כמה בעיות הוא מוצא. צריכים עזרה באוטומציה של תהליכי אבטחה ובדיקות? [הצוות שלנו ב-AI Buddy](/services/ai-agents) בונה סוכני AI שיכולים לנטר, לדווח, ולהתריע על בעיות אבטחה באופן אוטומטי. [דברו איתנו](/consulting) ונראה איך אפשר לעזור. אפשר גם לקרוא עוד על [אוטומציה לעסקים](/automation-for-business) שלנו. *עודכן לאחרונה: מרץ 2026* ## איך מתחילים: 5 צעדים לאבטחת אפליקציית מובייל 1. **בדיקת OWASP Top 10 Mobile (שבוע 1):** OWASP מפרסם את 10 הסיכונים הנפוצים ביותר במובייל. לקחו כל אחד ובדקו אחד אחד מול הקוד שלכם. זה לא עבודה של שעה, אבל ניתן לחלק. 2. **Penetration Testing על Staging (שבוע 2):** שכרו Pentester חיצוני לבדיקה בסביבת Staging. תמצאו חורים לפני שלקוחות ימצאו אותם. עלות: 5,000-15,000 שקל. זול מאירוע אבטחה. 3. **הגדרת מדיניות אבטחת נתונים (שבוע 2):** אילו נתוני משתמש אתם שומרים? לכמה זמן? מי יכול לגשת? מה קורה אם עוזב עובד? רשמו את זה. 4. **הגדרת תהליך Incident Response (שבוע 3):** מה קורה כשיש פרצת אבטחה? מי מוודא? מה אומרים למשתמשים? כמה מהר חייב לאטום? בלי תוכנית מוכנה, הבהלה עולה ביוקר. 5. **ניטור שוטף (לאחר השקה):** Sentry לניטור Crash, Firebase Analytics להתנהגות חשודה, ובדיקת Dependencies Vulnerability אחת לחודש.