Content Security Policy: שכבת ההגנה שחוסמת XSS לפני שהוא קורה

מאת צוות מדיה דיל · 31.08.2026 · אבטחת מידע · 7 דק׳ קריאה

CSP הוא כותרת HTTP שאומרת לדפדפן בדיוק אילו מקורות סקריפט מותרים לרוץ בדף. הגנה קריטית מפני XSS שהרבה אתרים עדיין לא מפעילים.

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

איך CSP עוצר XSS בפועל

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

script-src: ה-Directive הקריטי ביותר

מגדיר בדיוק מאילו מקורות מותר לטעון JavaScript. הגדרה מחמירה (רק הדומיין עצמו, בלי 'unsafe-inline') חוסמת כמעט כל וקטור XSS נפוץ — אבל דורשת שהאתר לא יסתמך על סקריפטים inline בתוך התגיות HTML עצמן.

הבעיה עם 'unsafe-inline'

אתרים רבים שמוסיפים CSP מוסיפים גם 'unsafe-inline' כי הם משתמשים בסקריפטים inline בכל מקום — אבל זה בעצם מבטל את רוב ההגנה מפני XSS, כי בדיוק כך גם קוד זדוני מוזרק יכול לרוץ. המעבר לקבצי סקריפט חיצוניים נקיים הוא הדרך הנכונה.

Nonce: פתרון לסקריפטים inline נחוצים

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

Report-Only: הטמעה הדרגתית ובטוחה

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

frame-ancestors: הגנה מפני Clickjacking

מעבר ל-XSS, CSP כולל גם הגנה מפני Clickjacking — קביעה מפורשת אילו אתרים (אם בכלל) מותר להם להטמיע את הדף שלכם בתוך iframe. ברירת מחדל מחמירה מונעת מאתר זדוני להטמיע את הדף שלכם בשקיפות ולתמרן משתמשים ללחוץ על אלמנטים נסתרים.

CSP כחלק מערימת הגנה, לא תחליף

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

connect-src: הגבלת יעדי הבקשות

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

תחזוקה שוטפת של המדיניות

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

רוצים לוודא שהאתר שלכם מוגן נכון מפני XSS? וואטסאפ.

strict-dynamic: פתרון לרשימות מקורות ארוכות ומסורבלות

אתרים מודרניים טוענים סקריפטים מכמה ספקים חיצוניים — אנליטיקס, כלי צ'אט, מערכות תשלום — כל אחד מהם צריך להופיע ברשימת המקורות המורשים, מה שהופך את המדיניות למסורבלת ולעיתים בלתי אפשרית לתחזק. הדירקטיבה 'strict-dynamic' פותרת זאת: סקריפט שכבר אושר (למשל דרך Nonce) מקבל הרשאה לטעון סקריפטים נוספים משלו, כך שרשימת המקורות המפורשת מתקצרת דרמטית ומתמקדת בנקודת הכניסה הראשונית, במקום בכל ספק חיצוני בנפרד.

Subresource Integrity: הגנה משלימה על סקריפטים חיצוניים

CSP קובע מאילו מקורות מותר לטעון סקריפט, אבל לא מוודא שהתוכן שבפועל מגיע ממקור מהימן לא שונה בדרך — למשל אם ספק חיצוני נפרץ ותוכן הקובץ שלו הוחלף. Subresource Integrity (SRI) מוסיף hash קריפטוגרפי צפוי לתגית הטעינה, כך שהדפדפן מסרב להריץ את הקובץ אם התוכן שהגיע לא תואם בדיוק למה שצפוי — הגנה משלימה ל-CSP, לא תחליף לו.

Hash-Based CSP: אלטרנטיבה ל-Nonce לתוכן סטטי

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

איסוף דיווחי הפרות בפועל: report-to

הדירקטיבה report-to (ההמשך המודרני ל-report-uri הישן) קובעת לאיזו כתובת הדפדפן ישלח דיווח מובנה בכל פעם שמדיניות CSP נחסמת בפועל, גם כשהמדיניות פועלת במצב אכיפה מלאה ולא רק ב-Report-Only. איסוף שיטתי של הדיווחים האלה לאורך זמן מאפשר לזהות לא רק תקלות תצורה, אלא גם ניסיונות תקיפה אמיתיים שהמדיניות בפועל חסמה — מידע ששווה לנטר ולא רק להגדיר ולשכוח.

CSP באפליקציות Single Page עם תוכן דינמי רב

אפליקציות מודרניות שנבנות כ-Single Page Application, ומזריקות תוכן ורכיבים דינמית דרך JavaScript, מציבות אתגר ייחודי ל-CSP: חלק ניכר מהתוכן לא קיים ב-HTML הראשוני אלא נוצר בזמן ריצה. מדיניות מחמירה מדי עלולה לחסום את מנגנוני העדכון הדינמי הלגיטימיים של הפריימוורק עצמו. הפתרון הנכון משלב בין Nonce שמתחדש בכל טעינה לבין תכנון קפדני של איך הפריימוורק מזריק תוכן, כדי שהאבטחה לא תבוא על חשבון הפונקציונליות הבסיסית של האפליקציה.

הגדרה דרך כותרת HTTP מול תגית meta

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

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

CSP לא פועל לבד — הוא בדרך כלל מוגדר יחד עם כותרות אבטחה נוספות כמו X-Content-Type-Options ו-Referrer-Policy, שכל אחת סוגרת פינה שונה של משטח התקיפה בדפדפן. אתר שמגדיר CSP חזק אבל מזניח את שאר הכותרות עדיין חשוף לווקטורים אחרים שאינם קשורים ישירות לטעינת סקריפטים. חשיבה על אבטחת הדפדפן כמערכת שלמה של כותרות משלימות, ולא כ-CSP בלבד, נותנת כיסוי הרבה יותר מקיף.

מדידת אפקטיביות: איך יודעים שה-CSP באמת עוזר

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

upgrade-insecure-requests: מעבר כפוי ל-HTTPS

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

תמיכת דפדפנים ותוכניות גיבוי (Fallback)

לא כל הדירקטיבות המתקדמות של CSP, כמו strict-dynamic או hash-based CSP, נתמכות באותה מידה בכל הדפדפנים והגרסאות הישנות שלהם. מדיניות CSP טובה נכתבת כך שדפדפן שלא מכיר דירקטיבה מתקדמת מסוימת פשוט מתעלם ממנה ונשאר עם ההגנה הבסיסית יותר שהוא כן מבין, במקום לקרוס או להתעלם מכל המדיניות. תכנון עם שכבות גיבוי כאלה מבטיח הגנה סבירה גם למשתמשים עם דפדפנים ישנים יותר.

שאלות נפוצות

האם CSP מגן גם מפני CSRF?

לא באופן ישיר. CSP מתמקד בעיקר בשליטה על אילו מקורות תוכן מותר לטעון בדף, ולכן חוסם XSS, בעוד CSRF דורש הגנות ייעודיות משלו כמו טוקן CSRF וקביעת מדיניות Cookie מתאימה. שני האיומים שונים ודורשים מנגנוני הגנה נפרדים, גם אם שניהם קשורים לאבטחת דפדפן.

האם CSP פוגע ב-SEO?

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

מה קורה כשספק חיצוני כמו כלי אנליטיקס לא נמצא ברשימת המקורות המורשים ב-CSP?

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

כמה קל להוסיף CSP לאתר קיים וישן?

תלוי מאוד בכמה סקריפטים inline ותלות בספקים חיצוניים כבר קיימים באתר. אתר שנבנה מלכתחילה בלי משמעת קפדנית סביב סקריפטים עלול לדרוש עבודת ניקוי משמעותית לפני שאפשר להפעיל מדיניות מחמירה, ולכן מומלץ להתחיל תמיד ב-Report-Only ולמפות את המצב הקיים לפני אכיפה.

האם CSP חוסם גם תמונות ופונטים חיצוניים, לא רק סקריפטים?

כן — מעבר ל-script-src, CSP כולל דירקטיבות נפרדות כמו img-src ו-font-src שמגדירות בדיוק מאילו מקורות מותר לטעון תמונות וגופנים. כל סוג משאב יכול לקבל מדיניות מקורות משלו, לא רק סקריפטים, מה שמאפשר בקרה מדויקת על כל התוכן שהדף טוען.

תגיות: Content Security Policy · CSP · XSS Protection · אבטחת דפדפן

← חזרה לבלוג · צור קשר