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

By Mirko Peters · 2026-04-23

אם אתם רציניים בנושא אבטחת אתרים, הבנת ההבדל בין מצבי ‘report-only’ ו-‘enforced’ ב-Content Security Policy (CSP) אינה פרט טכני משני, אלא העיקר…

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, חשוב להבין את שני המצבים העיקריים: 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 הבעייתית, איזו הנחיה הופרה ולעיתים גם דוגמה לקוד החשוד.

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

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 מהימנות, ואולי גם אחסון Blob של Microsoft Azure).

לתחביר יש משמעות. כל הנחיה מפרטת ערכים מותרים: כתובות URL, סכמות כמו ‘https:’, או מילות מפתח כמו ‘self’. אם מתירים סקריפטים inline (לפעמים נדרש בקוד מדור קודם), ייתכן שתצטרכו את ‘unsafe-inline’, אבל יש להיזהר – זה מחליש את ההגנה, אלא אם משתמשים בהאשים או 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 שלכם.
• מטרה: מצב דוח בלבד מאפשר לבדוק ולכוונן מדיניות ללא סיכון למשתמשים. מצב אכיפה נועד להגנה ממשית, והופך את כללי האבטחה לאפקטיביים.
• השפעה על משתמשים: מצב דוח בלבד אינו מורגש, והמשתמשים אינם מבחינים בו כלל. מצב אכיפה עלול לשבש תכונות או תוכן אם לא בדקתם את הכללים מראש.
• מקרי שימוש: מצב דוח בלבד מתאים במיוחד להטמעה הדרגתית, לניתוח סיכונים ולבדיקות תאימות למערכות מדור קודם. מצב אכיפה הוא השלב הסופי להשגת אבטחה חזקה ותואמת רגולציה.
• תאימות וסיכון: מצב דוח בלבד מסייע בניטור ובתיעוד במהלך ביקורות, ואילו מצב אכיפה מונע באופן ישיר פריצות אבטחה בזמן אמת.