אנחנו מוצאים את הסיכונים האמיתיים, מסבירים אותם בעברית פשוטה, ועוזרים לכם לתקן אותם.
תיקון 13 לחוק הגנת הפרטיות כבר בתוקף
התיקון בתוקף מאז 14 באוגוסט 2025, ותקופת החסד למינוי ממונה הגנת פרטיות הסתיימה ב-31 באוקטובר 2025. רשות הגנת הפרטיות מוסמכת כעת להטיל עיצומים כספיים בעצמה, בלי בית משפט: עד 5% מהמחזור השנתי, ולעסקים קטנים עד ₪140,000 בשנה. ביולי 2026 הוטל העיצום הראשון מכוח התיקון, ₪256,000, על דיווח באיחור על אירוע אבטחה.
בדיקת חשיפה חיצונית היא סקירה של כל מה שהעסק שלכם חושף לאינטרנט הפתוח — דומיינים ותת-דומיינים, הגדרות מייל, תעודות אבטחה, אתר ציבורי ומפתחות שדלפו — שמבוצעת מבחוץ, בלי סיסמאות ובלי גישה למערכות שלכם, ומסתיימת ברשימה מתועדפת של מה לתקן קודם.
לפי דוח IBM לשנת 2025, לוקח לארגונים 158 ימים בממוצע רק כדי לזהות שדלף מידע, ועוד 83 ימים עד להכלת האירוע. הבדיקה הזו נועדה לכך שתדעו ראשונים.
| Aegis | פנטסט מלא | סורק אוטומטי | |
|---|---|---|---|
| מחיר | ₪1,990 קבוע | ₪15,000–150,000 | 9–29$ לחודש |
| בקרה אנושית על כל ממצא | כן | כן | לא |
| הסבר בשפה של בעל העסק | כן | בדרך כלל לא | לא |
| בדיקה חוזרת כלולה | כן | לפעמים | לא |
| ניסיון פריצה פעיל | לא | כן | לא |
| זמן עד לתוצאות | 2–5 ימי עסקים | שבועות | מיידי |
טווחי המחירים של פנטסט מלא בישראל ושל סורקים אוטומטיים לקוחים ממחקר שוק פומבי. מקור למחירי פנטסט בישראל: Astra
סריקה של Symbiotic Security על 1,072 אפליקציות שנבנו בשיטת vibe coding מצאה שב-98% מהן יש לפחות פרצת אבטחה אחת. ביולי 2025 חוקרי Wiz מצאו ב-Base44 עצמה ליקוי שאיפשר לעקוף SSO ולהיכנס לאפליקציות פרטיות, עם ה-app_id שגלוי בכתובת האתר בלבד. אותה בדיקת אבטחה שלנו מכסה בדיוק את הדברים האלה.
Symbiotic Security — סריקת 1,072 אפליקציותWiz Research — Base44
לא רשימת מונחים טכניים — הסבר קצר על כל בעיה שאנחנו בודקים: מה הסיכון בפועל, ואיך מתקנים אותו. בלי לשלם לפני שאתם מבינים מה קניתם.
הבעיה: כל תת-דומיין ישן שנשאר פעיל — אתר בדיקות, פרויקט צד שממשיך לרוץ, שרת שכבר לא בשימוש — הוא דרך כניסה שאף אחד לא בודק. תוקפים סורקים בדיוק את מה שכולם שכחו.
איך מתקנים: מיפוי מלא של כל תת-דומיין פעיל, השוואה מול מה שבאמת בשימוש, וסימון כל מה שנשאר חשוף בלי סיבה.
הבעיה: בלי SPF, DKIM ו-DMARC מוגדרים נכון, כל אחד יכול לשלוח מייל שנראה כאילו הגיע מהדומיין שלכם — ללקוחות, לספקים ואפילו לעובדים. זה הבסיס לרוב מתקפות הפישינג המכוונות לעסקים.
איך מתקנים: בדיקת שלוש הרשומות מול הסטנדרט, איתור קונפיגורציה חלקית או שגויה, והמלצה מדויקת לתיקון בלי לשבור מיילים שכן אמורים לצאת.
הבעיה: תעודה שפג תוקפה, או הגדרת הצפנה ישנה, גורמת לדפדפן להציג אזהרה למבקרים — פוגעת באמון — ובמקרים חמורים מאפשרת ליירט תקשורת.
איך מתקנים: בדיקת תוקף התעודה, פרוטוקולי ההצפנה הנתמכים, ודירוג מול הסטנדרט המקובל בתעשייה.
הבעיה: פאנל ניהול, ממשק מסד נתונים או שירות פנימי שנשאר נגיש מבחוץ בטעות — נקודת כניסה ישירה למי שמוצא אותו, בלי צורך לפרוץ שום דבר.
איך מתקנים: זיהוי כל שירות פתוח, הערכת רגישותו, והמלצה להגביל גישה לרשת פנימית או VPN בלבד.
הבעיה: אם השרת עונה "כן" לכל אתר שמבקש גישה למידע, כל אתר זר יכול לקרוא מידע רגיש ישירות מהדפדפן של משתמש מחובר.
איך מתקנים: בדיקת תגובת השרת מול מקורות שונים, והגבלתו לרשימת דומיינים מפורשת שבאמת צריכה גישה.
הבעיה: בלי טוקן הגנה בטפסים, אתר זדוני יכול לגרום לדפדפן של משתמש מחובר לשלוח פעולה בלי שהוא ידע — שינוי הגדרות, רכישה או מחיקה.
איך מתקנים: בדיקת נוכחות טוקן הגנה בכל טופס שמבצע פעולה, והמלצה להוסיף אותו היכן שחסר.
הבעיה: בלי כותרות כמו Strict-Transport-Security, X-Content-Type-Options ו-Content-Security-Policy, הדפדפן לא מקבל את ההנחיות הבסיסיות להגנה — פותח דלת ל-clickjacking ולהתקפות דומות.
איך מתקנים: רשימה מלאה של הכותרות החסרות, מדורגת לפי חשיבות, עם ההגדרה המדויקת להוספה.
הבעיה: תוסף או תבנית ישנה ב-WordPress היא אחת הדרכים הנפוצות ביותר לפרוץ לאתרים קטנים — עם חולשות ידועות ומתועדות שכל תוקף יכול לחפש.
איך מתקנים: זיהוי גרסת הליבה, התוספים והתבניות הפעילים, והשוואה מול מאגר חולשות ידועות (CVE).
הבעיה: קובץ הגדרות, .git, .env או קובץ תלויות שנשאר נגיש בפומבי חושף מבנה פנימי, ולפעמים ממש סיסמאות או מפתחות.
איך מתקנים: סריקה שיטתית של נתיבים ידועים לבעייתיות, וזיהוי כל קובץ שלא אמור להיות ציבורי.
הבעיה: תיקיות כמו /admin, /backup או /internal שנגישות בלי הגנה מזמינות ניסיונות גישה — גם בלי חולשה ישירה, הן מרחיבות את מה שתוקף יודע עליכם.
איך מתקנים: מיפוי נתיבים בעלי שם רגיש, וסימון כל אחד מהם לבדיקה ידנית.
הבעיה: כשקלט של משתמש מגיע ישירות לשאילתת מסד הנתונים בלי סינון, תוקף יכול לשנות את השאילתה ולחלץ, לשנות או למחוק מידע — כולל נתוני לקוחות.
איך מתקנים: בדיקה בטוחה עם סימן בדיקה שפיר, ללא חילוץ מידע אמיתי — כל ממצא עובר אימות אנושי לפני שנחשב מאושר.
הבעיה: אם קלט שהמשתמש מזין חוזר לדף בלי סינון, תוקף יכול להזריק קוד שירוץ בדפדפן של קורבן אחר — גניבת עוגיות או השתלטות על חשבון.
איך מתקנים: בדיקה עם סמן שפיר בלבד, וזיהוי היכן הפלט לא עובר בריחה (escaping) לפני הצגה.
הבעיה: כל ספרייה, פלאגין או שרת עם גרסה ישנה עלול לשאת חולשה ידועה ומתועדת בפומבי — אלפי כלים אוטומטיים סורקים בדיוק את זה.
איך מתקנים: השוואת כל רכיב וגרסה מול מאגר CVE עדכני, ותעדוף לפי חומרה אמיתית.
הבעיה: פרמטר שמקבל כתובת URL, קובץ XML או נתיב קובץ בלי בדיקה עלול לאפשר לתוקף לגרום לשרת לגשת למשאבים פנימיים שלא אמורים להיות נגישים מבחוץ.
איך מתקנים: זיהוי דפוס חשוד בפרמטרים, בלי ניצול בפועל, וסימון לבדיקה ידנית מדויקת.
הבעיה: כלים כמו Lovable ו-Replit מקלים על הפרסום, אבל לפעמים גם על השארת מפתח API בקוד שנשלח לדפדפן — כל מי שפותח את כלי הפיתוח רואה אותו.
איך מתקנים: סריקת חבילת הקוד שנשלחת לדפדפן, וזיהוי כל מפתח שאמור להיות בשרת בלבד.
הבעיה: כשה-RLS כבוי, כל מי שיש לו את המפתח האנונימי הציבורי (שנמצא ממילא בכל דפדפן) יכול לקרוא — ולפעמים לכתוב — ישירות לטבלאות שאמורות להיות פרטיות.
איך מתקנים: בדיקה קריאה-בלבד מול המפתח האנונימי החשוף ממילא: האם טבלה שלא אמורה להיות ציבורית מחזירה מידע.
הבעיה: המפתח הזה עוקף לחלוטין את כל הגדרות ה-RLS — אם הוא נמצא בקוד שנשלח לדפדפן, כל מי שמוצא אותו קיבל גישה מלאה למסד הנתונים.
איך מתקנים: זיהוי המפתח לפי המבנה הייחודי שלו, ודגל קריטי מיידי לרוטציה.
הבעיה: בלי כללי הרשאה מוגדרים, מסד הנתונים של Firebase עונה לכל בקשה — אפילו בלי שום אימות.
איך מתקנים: בדיקה פסיבית: פנייה לנקודת הקצה הציבורית בלי טוקן, ובדיקה אם היא מחזירה מידע אמיתי.
הבעיה: אם נקודת הקצה של הצ'אט לא דורשת התחברות, כל אחד יכול לפנות אליה ישירות ולנצל את מכסת ה-API בתשלום שלכם — בלי לגנוב כלום, רק לחייב אתכם.
איך מתקנים: בדיקה עם קריאה מינימלית אחת: האם נקודת הקצה עונה בלי שום אימות.
הבעיה: הודעה פשוטה כמו "התעלם מההוראות הקודמות" יכולה לגרום למודל לחשוף את ההנחיות שקיבל — ולפעמים לוגיקה עסקית או מידע שלא אמור להיות פומבי.
איך מתקנים: בדיקה עם הודעה שפירה אחת, מחפשת סימנים לשוניים אופייניים להנחיה פנימית — רק כשיש הרשאה מפורשת לבדיקה כזו, כי היא צורכת שימוש אמיתי בתשלום.
הבעיה: אם התשובה של הבינה המלאכותית מוצגת בדף בלי בריחה (escaping), והצלחה להזריק תוכן למודל הופכת ל-XSS מלא נגד כל מי שרואה את אותה שיחה.
איך מתקנים: בדיקה סטטית של הקוד לאיתור הצגה לא בטוחה של תשובות, בתוספת המלצה לסנן HTML לפני הצגה.
הבעיה: אם לסוכן יש הרשאה לכתוב למסד הנתונים או לשלוח מיילים בלי אישור אנושי, הזרקת הוראות מוצלחת יכולה לגרום לו לבצע פעולה אמיתית בלי שאף אחד התכוון לזה.
איך מתקנים: לא בודקים ישירות — בדיקה שמצליחה כבר תגרום לנזק אמיתי. במקום זה, שואלים בפגישת התוצאות ומייעצים על אישור אנושי לפני כל פעולה בלתי הפיכה.
כל ממצא נסקר אישית על ידי אלברט נוימן, מייסד Clarvix ובעל תעודת Offensive Security Expert ממכללת איקום (360 שעות לימוד, 2025) — לא מעתיקים פלט גולמי של כלי סריקה.
אחרי התיקונים, אנחנו בודקים שוב ומוודאים שהתיקון אכן עבד.
אף אחד לא יכול להבטיח אבטחה מוחלטת, ואנחנו לא מתיימרים להבטיח את זה.
Clarvix