למה מצב Report-Only שונה ממצב Enforced ב-Content Security Policy

By Mirko Peters · 2026-04-23

אם אתם רציניים בנושא אבטחת רשת, ההבדל בין מצבי ‘report-only’ ל-‘enforced’ ב-Content Security Policy הוא הרבה יותר מפרט טכני—זה העיקר. מצב Report-Only מאפשר לראות מה היה נחסם לפי המדיניות שלכם, בלי לעצור שום דבר בפועל, והאתר הופך למעין מגרש אימונים לבדיקות אבטחה. לעומתו, מצב Enforced לא מתלבט: הוא חוסם כל מה שסותר את המדיניות ונועל את האתר בזמן אמת.

Automatically translated with AI from the original post. Read the English original

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

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

הבנת מצבי CSP וההשפעה שלהם

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

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

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

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

איך Content-Security-Policy-Report-Only עובד לצורך דיווח על הפרות

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

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

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

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

איך מצב Enforced מגביר את האבטחה

מצב אכיפה הוא השלב שבו מדיניות ה-CSP שלך מפסיקה להיות המלצה והופכת לכלל מחייב. כשמשתמשים בכותרת Content-Security-Policy, הדפדפנים חוסמים בפועל כל תוכן שאינו תואם להנחיות שהגדרת – בלי אזהרות, רק פעולה.

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

יישום דיווח באמצעות נקודות קצה מסוג Report-URI ו-Report-To

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

ההנחיה report-uri היא השיטה הישנה: מגדירים כתובת URL, והדפדפנים שולחים אליה את הדוחות ישירות. עם זאת, לגמישות מודרנית ולדיווח עשיר יותר, report-to היא האפשרות החדשה והחזקה יותר – במיוחד ככל שהדפדפנים מרחיבים את התמיכה שלהם ב-Reporting API. report-to עובדת עם קבוצה בעלת שם שיכולה לטפל בסוגים שונים של דוחות ומציעה שליטה טובה יותר בסינון.

בעת הגדרת נקודות הקצה הללו, יש לאבטח אותן – HTTPS, בקרות גישה וניטור לזינוקים בלתי צפויים (שעלולים להעיד על התקפה או על מדיניות שבורה). וגם לא לשכוח את הפרטיות: דוחות עשויים להכיל כתובות URL ואף קטעים של סקריפט פוגעני, ולכן עליכם להיות מוכנים לנקות מידע רגיש לפני אחסון או שיתוף שלהם, ולשים לב לרגולציות כמו GDPR ו-CCPA.

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

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

כתיבת כותרת CSP איכותית אינה מדע טילים, אך היא דורשת תשומת לב לפרטים – במיוחד כשמתמודדים עם אפליקציות מורכבות ושילובים בענני Microsoft. ביסוד הדברים, מדיניות CSP היא רשימה מובנית של הנחיות, שכל אחת מהן אומרת לדפדפנים מה מותר ומה אסור. שולחים מדיניות אלו דרך כותרות HTTP, בדרך כלל כ-Content-Security-Policy או כ-Content-Security-Policy-Report-Only, בתבנית של מחרוזות שבהן הכללים מופרדים בנקודה-פסיק.

לב המדיניות טמון בהנחיות מרכזיות כמו default-src, script-src ו-img-src. default-src היא ברירת המחדל – אם לסוג תוכן מסוים אין כלל משלו, הדפדפן בודק את זה. script-src ו-img-src מתמקדות בסקריפטים ובתמונות, ומאפשרות לשלוט בהידוק במקורות מהימנים (חשבו על הדומיינים שלכם, רשתות CDN מהימנות, ואולי גם Azure blob של Microsoft).

התחביר חשוב. כל הנחיה מפרטת ערכים מותרים: כתובות URL, סכמות כמו ‘https:’, או מילות מפתח כמו ‘self’. אם אתם מאפשרים סקריפטים inline (לעיתים נדרש לקוד מדור קודם), ייתכן שתצטרכו את ‘unsafe-inline’. אך יש להיזהר – אפשרות זו מחלישה את ההגנה, אלא אם משתמשים ב-script hashes או ב-nonces לאימות נוסף.

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

שיטות עבודה מומלצות למעבר ממצב Report-Only למצב אכיפה

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

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

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

לעולם אל תמעיטו בערך הבדיקות. השתמשו בכלי המפתחים של הדפדפן, בבודקי סטטוס של CSP ואף בסריקות אוטומטיות ב-CI/CD כדי לוודא שהמדיניות פועלת כצפוי. המטרה הסופית? יישום נעול, תואם לדרישות ועמיד, שמוגן על ידי מדיניות שנבחנה בעולם האמיתי ולא על סמך משאלות לב.

דוגמאות מהעולם האמיתי ל-CSP במצבי דיווח בלבד ואכיפה

שום דבר לא מחיה את CSP כמו דוגמאות אמיתיות. במצב דיווח בלבד תוכלו להשתמש בכותרת כמו: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://csp-report.example.com. הגדרה כזו מתעדת כל הפרה אך אינה מפריעה למשתמשים, ולכן היא מתאימה במיוחד לבדיקות בסביבת ייצור ללא סיכון.

לעומת זאת, מדיניות באכיפה: Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src 'self'; report-uri https://csp-report.example.com. כעת הדפדפן חוסם בפועל כל סקריפט או תמונה שאינם תואמים לכללים, ומגן על המשתמשים מיד מפני תוכן שלא אושר.

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

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

סיכום ההבדלים המרכזיים בין מצב דיווח בלבד למצב אכיפה

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