📋 תוכן עניינים
חשוב להקדים: אלה לא באגים נדירים. הן חוזרות כי מודל שמייצר קוד עושה אופטימיזציה למה שעובד בהדגמה, לא למה ששורד באינטרנט הפתוח.
1. מפתחות API בקוד הצד־לקוח
זו הפרצה מספר אחת. המודל צריך לחבר את האתר לשירות חיצוני — מייל, מסד נתונים, מודל AI — ומטמיע את המפתח ישירות בקוד שנשלח לדפדפן. כל גולש יכול לפתוח את מקור הדף ולקחת אותו.
איך לבדוק: Ctrl+U במקור הדף, חיפוש של key, secret, token, או תחילית כמו sk_. אם מצאתם מפתח — הוא כבר חשוף ויש להחליף אותו מיד, לא רק להסתיר.
הפתרון: כל קריאה לשירות בתשלום עוברת דרך השרת. המפתח יושב במשתנה סביבה, לא בקוד.
2. הרשאות מסד נתונים פתוחות לכל
בילדרים שמחוברים לשירותי מסד נתונים מנוהלים מייצרים ברירת מחדל נדיבה מדי — לעיתים קריאה וכתיבה לכל טבלה לכל מבקר. זה עובד מושלם בפיתוח וזו דלת פתוחה בייצור.
הפתרון: כלל הרשאות מפורש לכל טבלה. ברירת המחדל צריכה להיות חסימה, וכל הרשאה נפתחת במכוון.
3. אין ולידציה בצד השרת
המודל מוסיף בדיקות לטופס — שדה חובה, פורמט מייל — אבל רק בדפדפן. תוקף לא משתמש בדפדפן; הוא שולח בקשה ישירה ומדלג על כל הבדיקות. התוצאה היא הזרקת תוכן, רשומות זבל, ולפעמים גישה לנתונים.
הכלל: ולידציה בדפדפן היא נוחות למשתמש. ולידציה בשרת היא האבטחה. חייבות להיות שתיהן.
4. טפסים בלי הגנה מפני בוטים
טופס יצירת קשר בלי rate limiting ובלי הגנה נגד ספאם יתמלא תוך שבועות. הנזק אינו רק הצפה בפניות מזויפות — כתובת המייל שממנה נשלחות התראות עלולה להיכנס לרשימות שחורות, ואז גם פניות אמיתיות מפסיקות להגיע.
5. חשיפת נתיבים ושגיאות
אתרי AI נשארים לעיתים במצב פיתוח, ואז שגיאה מציגה לגולש את מסלול הקבצים בשרת, שם מסד הנתונים ולפעמים חלקי קוד. זה מידע מובנה שמאפשר לתקוף ממוקד.
הפתרון: הצגת שגיאות מכובה בייצור, עם עמוד שגיאה כללי לגולש ורישום מלא ביומן פנימי.
6. אין ניהול סשן תקין באזורים מוגנים
אם באתר יש אזור אישי, נפוץ למצוא בדיקת הרשאה שמתבצעת רק בממשק — הקישור מוסתר מהתפריט, אבל הכתובת עצמה נגישה לכל מי שמנחש אותה. הסתרה אינה הרשאה.
7. תלויות לא מעודכנות
המודל מייצר קוד עם ספריות בגרסאות שהיו נפוצות בזמן האימון שלו, ולעיתים כאלה עם פרצות מתועדות. האתר עולה לאוויר עם חוב אבטחה מהיום הראשון, ואין שום מנגנון שיודיע לכם על כך.
8. אין גיבוי
לא פרצה במובן הקלאסי, אבל זה מה שהופך תקלה לאסון. בילדרים רבים אינם מייצרים גיבוי שאתם שולטים בו. אם התוכן נמחק או השירות משתנה — אין ממה לשחזר.
הכלל: גיבוי שאתם לא יכולים לשחזר ממנו בעצמכם, בלי תלות בספק, אינו גיבוי.
9. אין ניטור
אתר שנפרץ ממשיך להיראות תקין. בלי ניטור שינויי קבצים ובלי התראה על נפילה, גילוי הפריצה קורה כשגוגל מסמנת את האתר כמסוכן — כלומר אחרי שהנזק התדמיתי כבר נוצר.
סדר טיפול לפי סיכון
| עדיפות | פרצה | נזק אפשרי | מאמץ |
|---|---|---|---|
| 1 | מפתחות חשופים | חיוב כספי, גישה לנתונים | שעות |
| 2 | הרשאות DB פתוחות | דליפת נתוני לקוחות | שעות |
| 3 | אין ולידציה בשרת | הזרקה, ספאם | בינוני |
| 4 | אין גיבוי | אובדן מלא | שעות |
| 5 | חשיפת שגיאות | מידע לתוקף | דקות |
שלושת הראשונים מכסים את רוב החשיפה האמיתית. השאר חשובים אבל פחות דחופים.
מה זה אומר לעסק
הנקודה שקל לפספס: האחריות המשפטית על נתוני לקוחות היא שלכם, לא של הבילדר. אם טופס באתר אוסף שמות וטלפונים ומסד הנתונים פתוח — זו חשיפה שלכם מול תיקון 13 לחוק הגנת הפרטיות, גם אם לא כתבתם שורת קוד אחת.
זו הסיבה שאנחנו כוללים סקירת אבטחה בכל חבילת ניהול אתרים, ולא מתייחסים אליה כתוספת. גם בחירת האחסון משנה כאן — חומת אש, גיבויים אוטומטיים וניטור הם חלק מהתשתית ולא משהו שמוסיפים אחר כך.
רוצים לדעת מה חשוף אצלכם? אנחנו עושים סקירת אבטחה ראשונית ללא עלות שבודקת את תשע הנקודות האלה ומחזירה דוח לפי סדר דחיפות.
איך בודקים כל פרצה בפועל — נוהל של 20 דקות
אין צורך בכלים בתשלום או בידע בפיתוח כדי לזהות את הרוב. זה הסדר שאנחנו עוברים בכל אבחון:
- מפתחות חשופים. פתחו את האתר, Ctrl+U, ואז Ctrl+F. חפשו בתורו:
api,key,secret,token,sk_,Bearer. בדקו גם את קבצי ה-JavaScript שהדף טוען — הם מופיעים בתגיות script עם כתובת. - שגיאות חושפות. הוסיפו לכתובת אחת הסיומות
/?test[]=1או/nonexistent-page-xyz. אם חוזר מסלול קבצים בשרת, שם מסד נתונים או trace — הצגת השגיאות פתוחה. - ולידציה בשרת. פתחו טופס, מלאו שדה מייל בערך לא תקין כמו
abc, ואז כבו JavaScript בדפדפן ושלחו. אם הרשומה נכנסה — אין בדיקה בשרת. - הגנת בוטים. שלחו את אותו טופס חמש פעמים ברצף. אם כל חמשת המשלוחים עברו בלי השהיה, בלי אתגר ובלי חסימה — אין rate limiting.
- אזורים מוגנים. אם יש אזור אישי, התנתקו והדביקו ישירות כתובת של עמוד פנימי. אם הוא נטען — ההגנה היא הסתרה בלבד.
- תלויות. חפשו במקור הדף שמות ספריות ומספרי גרסה. הצליבו מול מסד הפרצות הציבורי של אותה ספרייה.
- גיבוי. הבדיקה האמיתית היא לא אם קיים גיבוי אלא אם אתם מצליחים לשחזר ממנו בעצמכם. אם לא ניסיתם — אין לכם גיבוי, יש לכם הנחה.
שימו לב לסדר. אם מצאתם מפתח חשוף בשלב 1, עצרו והחליפו אותו לפני שתמשיכו. מפתח שהיה גלוי אפילו שבוע נחשב דלוף — סורקים אוטומטיים מסרקים מקורות דפים ומאגרי קוד באופן שוטף.
מה זה עולה כשזה קורה
הפער בין "פרצה תיאורטית" ל"נזק" הוא מה שמזיז בעלי עסקים לפעולה. אלה התרחישים שראינו בפועל, ומה כל אחד עלה:
| מה קרה | הנזק הישיר | הנזק העקיף |
|---|---|---|
| מפתח מודל AI דלף | חיוב על שימוש של גורם זר | חסימת החשבון, האתר מפסיק לעבוד |
| טבלת לידים נקראה | אין עלות מיידית | חשיפה מול תיקון 13, חובת דיווח |
| טופס הוצף בספאם | שעות סינון | כתובת המייל נכנסת לרשימה שחורה |
| קוד זדוני הוזרק | עלות ניקוי | גוגל מסמנת כמסוכן, התנועה נעצרת |
| תוכן נמחק ואין גיבוי | בנייה מחדש | אובדן דירוגים שנצברו לאורך חודשים |
שימו לב לעמודה השלישית: כמעט בכל שורה הנזק העקיף גדול מהישיר. זו הסיבה שהערכת סיכון לפי "כמה כסף אפשר לגנוב ממני" מפספסת את התמונה.
מה עושים ב-24 השעות הראשונות אחרי פריצה
אם כבר קרה, הסדר קובע. הטעות הנפוצה היא להתחיל מניקוי — ואז התוקף חוזר דרך אותה דלת.
- לבטל אישורים, לא להסתיר. כל מפתח, סיסמה וטוקן שהיו נגישים — לבטל ולהנפיק מחדש. זה קודם לכל דבר אחר.
- לתעד לפני שמנקים. צילומי מסך, יומני שרת, תאריכי שינוי קבצים. אחרי ניקוי אין דרך לדעת מה נגעו ומה נלקח, וזה מה שקובע אם קמה חובת דיווח.
- לסגור את נתיב הכניסה. לזהות איך נכנסו ולתקן את הפרצה עצמה. ניקוי בלי סגירה הוא רק דחייה.
- לשחזר מגיבוי שקדם לפריצה. ולא מהגיבוי האחרון — הוא כבר עלול להכיל את הקוד הזדוני.
- לבדוק אם נגעו בנתונים אישיים. אם כן, מתחילות חובות דיווח לפי חוק הגנת הפרטיות.
- לבקש בדיקה מחדש בגוגל. אם האתר סומן, הסימון לא יורד לבד — יש להגיש בקשה ב-Search Console.
ההיבט הרגולטורי — תיקון 13
זה החלק שהופך את הנושא מטכני לעסקי. תיקון 13 לחוק הגנת הפרטיות, שנכנס לתוקף באוגוסט 2025, החמיר משמעותית את המשמעות של דליפת מידע אישי בישראל.
שלוש נקודות שרלוונטיות ישירות לאתר שנבנה ב-AI:
- בעל העסק שאוסף את המידע הוא בעל השליטה בו, והאחריות עליו — לא על ספק הכלי שבו נבנה האתר
- אירוע אבטחה שנוגע במידע אישי מחייב טיפול ותיעוד, ובמקרים מסוימים דיווח
- סמכויות האכיפה והעיצומים הכספיים הורחבו מול המצב הקודם
ההשלכה המעשית: אם אתם לא בטוחים שהטופס באתר מאובטח, שקלו לצמצם את מה שהוא אוסף. טופס שמבקש שם וטלפון בלבד יוצר חשיפה קטנה בהרבה מטופס שאוסף כתובת, תאריך לידה או מידע רפואי. איסוף מידע שאינכם צריכים הוא סיכון בלי תמורה.
מינימום ההגנה שכל אתר צריך
גם אתר תדמית קטן. זו לא רשימת שאיפות אלא רצפה:
| רכיב | למה | עלות טיפוסית |
|---|---|---|
| תעודת SSL | הצפנת התנועה, דרישת בסיס של גוגל | חינם |
| גיבוי אוטומטי חיצוני | שחזור בלי תלות בספק | נמוכה |
| חומת אש לאפליקציה | חסימת סריקות וניסיונות אוטומטיים | נמוכה עד בינונית |
| סודות בצד השרת | מונע את הפרצה הנפוצה ביותר | עבודה חד-פעמית |
| ולידציה בשרת | מונע הזרקה וספאם | עבודה חד-פעמית |
| ניטור זמינות | לדעת על נפילה לפני הלקוחות | חינם עד נמוכה |
שש השורות האלה מסירות את מרבית החשיפה. אף אחת מהן אינה יקרה — הן פשוט לא נכללות בברירת המחדל של בילדר AI.
לקבל מאמרים כאלה ישירות למייל?
הרשמה חינמית. מאמרים חדשים + קורסים — ישירות לתיבה שלך. ללא ספאם, הסרה בקליק.
ללא ספאם · הסרה בקליק אחד · כבר 32+ מנויים
