Defaults.Exposed › תיקונים › Content-Security-Policy (CSP)

כיצד לתקן Content-Security-Policy (CSP)

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

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

מה זה יכול לעלות לכם

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

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

מה זה, בשפה פשוטה

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

מדיניות אבטחת תוכן (מקוצר לרוב CSP) היא רשימת כללים קצרה שהאתר שלך מצרף לכל דף, שאומרת לדפדפן: “הרץ רק קוד ממקורות אלה שאישרתי, ותסרב לכל השאר.” זוהי ההבדל בין מועדון שנותן לכל אחד להיכנס לבין אחד עם רשימת אורחים בדלת.

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

מה זה יכול לעלות לך

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

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

• טופס התשלום המזויף. רמאי מזריק תיבת “שלם כאן” משכנעת לאתר האמיתי שלך. לקוחות מזינים פרטיהם בסמוך למותג שלך; הכסף והמידע הולכים לתוקף. הלקוחות מאשימים אותך — ואין הם טועים, כי זה קרה באתר שלך.

• החוזה שאבד. הלקוח הגדול הפוטנציאלי של צוות האבטחה מריץ סריקה אוטומטית של האתר שלך כחלק מבדיקת נאותות של ספקים. מדיניות אבטחת תוכן חסרה מופיעה מיד כפרצה בחומרה גבוהה. לסוקר רכש או אבטחה, אמצעי הגנה יחיד חסר זה קורא “ספק זה לא עושה את הבסיסיים” — והעסקה עוצרת בזמן שהם מבקשים תיקון, או עוברת בשקט למתחרה שעבר.

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

• הפרסומת או הווידג’ט שנפגעו. אתרים רבים טוענים קוד מגורמי חוץ — רשתות פרסום, גופנים, צ’אט תמיכה, אנליטיקה. אם אחד מאלה נפרץ, הקוד הזדוני נוסע ישירות לדפים שלך. מדיניות אבטחת תוכן מגבילה את רדיוס הנזק ע”י מתן אפשרות רק למקורות החיצוניים הספציפיים שאתה סומך עליהם, כך שהפרצה של ספק אחד לא הופכת אוטומטית לשלך.

מה זה בעצם (הפרטים)

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

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

בשפה פשוטה, זה אומר: כברירת מחדל, טען רק דברים מהאתר שלי; הרץ רק סקריפטים מהאתר שלי; אל תאפשר תוספי ישן; ואל תאפשר לאתרים אחרים להטמיע שלי במסגרת.

מה נראה “טוב”. הבדיקה שלנו לא מחפשת רק את נוכחות הכותרת — היא קוראת את המדיניות הוראה אחר הוראה ומנקדת עד כמה היא חזקה בפועל, בדרך שסוקר אבטחה היה עושה. מדיניות חזקה:

• מגדירה בסיס מגביל (default-src 'self') ומרחיבה אותו רק עבור גורמי הצד השלישי המהימנים הספציפיים שאתה באמת משתמש בהם.
• נמנעת מהפרצות. היא לא משתמשת ב-'unsafe-inline' או 'unsafe-eval' עבור סקריפטים, ולא משתמשת ב-wildcard (*) או מקורות scheme בלבד (כמו https:) עבור סקריפטים — אלה פותחים מחדש בפועל את הדלת שהמדיניות אמורה לסגור. כשסקריפטים inline באמת נדרשים, היא משתמשת בנוס (nonce) או עיכול (hash) כדי שרק הקוד המאושר הספציפי שלך ירוץ.
• נועלת הסגרה עם frame-ancestors 'self' (זה גם חוסם את התקפת “הטמע את האתר שלך כדי להטעות את לקוחותיך”) ומשבית תוספים ישנים עם object-src 'none'.
• אוכפת, לא דיווח-בלבד. כותרת Content-Security-Policy-Report-Only רק צופה; היא מספקת אפס הגנה בזמן ריצה. הבדיקה שלנו נותנת לה חלק קטן מהנקודות ולעולם לא רושמת אותה כמעבר. אתה מוגן רק ברגע שהמדיניות אוכפת.

מדיניות שקיימת אך נשענת על 'unsafe-inline', 'unsafe-eval', או wildcards עדיין תנקד נמוך — כיוון שבפועל היא מספקת מעט הגנה אמיתית. המטרה היא מדיניות הדוקה, לא סתם מדיניות כלשהי.

כיצד לתקן (חינם, ~1–2 שעות)

מסור זאת לאיש ה-IT שלך או למי שמריץ את האתר שלך — התיקון עצמו חינמי לחלוטין. אנחנו גובים תשלום רק לניטור שהוא נשאר במקום ונכון לאורך זמן; הפעלתו לא עולה כלום. הסיבה שזה לוקח שעה-שתיים ולא דקות היא שלב הניסיון הזהיר שעוצר אותו מחסום בטעות חלקים מהאתר שלך.

1. התחל במצב דיווח-בלבד — אל תאכוף עדיין. הוסף כותרת תגובת Content-Security-Policy-Report-Only. זה צופה ורושם מה היה נחסם ללא חסימה בפועל, כך שהאתר החי ממשיך לעבוד בזמן שאתה לומד על מה כל דף תלוי באמת. (חשוב: דיווח-בלבד בפני עצמו אינו מספק למבקרים הגנה — זה רק הצעד הראשון הבטוח.)

2. בנה את המדיניות ממה שהאתר שלך באמת משתמש בו. סקור את הדיווחים כדי למצוא כל מקור לגיטימי של סקריפטים, סגנונות, גופנים, ותמונות — הדומיין שלך, האנליטיקה שלך, ספק התשלומים שלך, מארח הגופנים שלך, ווידג’ט הצ’אט שלך — ורשום אותם כמקורות מותרים. נקודת פתיחה מוצקה היא default-src 'self' בנוסף לרשומות מפורשות לגורמי הצד השלישי המהימנים שאתה באמת משתמש בהם.

3. הימנע מהפרצות שמבטלות את כל המטרה. התרחק מ-'unsafe-inline' ו-'unsafe-eval' עבור סקריפטים, והימנע ממקורות wildcard כמו * ו-schemes בלבד כמו https: עבור סקריפטים — אלה פותחים מחדש בדיוק את הפרצה שהמדיניות אמורה לסגור. כשסקריפטים inline בלתי נמנעים, השתמש בנוס (nonce) או עיכול (hash) כדי שרק הקוד המאושר הספציפי שלך ירוץ.

4. נעל הסגרה ותוספים. הוסף frame-ancestors 'self' (זה גם עוצר אתרים אחרים מהטמעת שלך כדי להטעות את לקוחותיך, ומספק את בדיקת ה-clickjacking הקשורה) ו-object-src 'none' לחסימת התקפות מבוססות תוסף ישנות.

5. עבור מדיווח-בלבד לאכיפה. לאחר שהדיווחים נקיים והאתר עובד, שנה את שם הכותרת מ-Content-Security-Policy-Report-Only ל-Content-Security-Policy. זה הצעד שמספק הגנה בפועל — מדיניות דיווח-בלבד לבדה לא, ולא תעבור את הבדיקה.

   היכן שאתה מגדיר את הכותרת תלוי בפלטפורמה שלך:

   • Cloudflare: Rules → Transform Rules → Modify Response Header → הגדר Content-Security-Policy. (אתה יכול להשתמש ב-Cloudflare גם לניסיון הדיווח-בלבד.)
   • Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
   • Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
   • IIS (web.config): הוסף כותרת תגובת HTTP מותאמת בשם Content-Security-Policy עם המדיניות כערכה.
   • Google Workspace / Microsoft 365: אלה מריצים את האימייל שלך, לא את האתר הציבורי שלך, אז המדיניות נקבעת היכן שהאתר שלך מתארח בפועל (Cloudflare או מארח האינטרנט שלך למעלה), לא במסוף האדמין לאימייל שלך.

6. בדוק מחדש את הדומיין שלך כדי לאשר שהמדיניות מוצגת כעת כמופעלת ואוכפת, ללא פרצות מחלישות.

טעויות נפוצות

• עצירה בדיווח-בלבד. השגיאה הנפוצה ביותר: מדיניות מתווספת במצב דיווח-בלבד, כולם ממשיכים, והאתר לעולם לא מוגן בפועל. דיווח-בלבד לא חוסם כלום. אתה חייב לעבור לאכיפה.
• פנייה ל-'unsafe-inline' כדי שזה “פשוט יעבוד.” כשהמדיניות חוסמת סקריפט inline לגיטימי, התיקון המהיר הוא לאפשר כל סקריפט inline — אבל זה פותח מחדש בדיוק את החור שהמדיניות נועדה לסגור. השתמש במקום זאת בנוס (nonce) או עיכול (hash).
• שימוש ב-wildcard. כוכבית בלבד * (או https:) ב-script-src מאפשרת סקריפטים מכל מקום, כלומר המדיניות מספקת כמעט ללא הגנה אמיתית ועדיין תנקד נמוך.
• שכחת מקורות צד שלישי. אכיפת מדיניות הדוקה מבלי לרשום תחילה את השירותים החיצוניים הלגיטימיים שאתה משתמש בהם (אנליטיקה, גופנים, ווידג’טים לתשלום) יכולה לשבור חלקים מהאתר שלך — וזו בדיוק הסיבה שקיים שלב הניסיון של דיווח-בלבד.
• הגדרתו רק בדף הבית. המדיניות צריכה לכסות כל דף, ובמיוחד קופה, כניסה, ודפי חשבון — אלה הדפים ששווה לתקוף.
• התייחסות אליו כתחליף למנעול. מדיניות אבטחת תוכן ו-HTTPS/HSTS מגינים על דברים שונים. אתה רוצה את כולם; אחד לא מכסה בשביל אחר.

שאלות נפוצות