מדיניות בנושא אבטחת תוכן

Content Security Policy יכולה לצמצם באופן משמעותי את הסיכון ואת ההשפעה של התקפות סקריפטים חוצי-אתרים בדפדפנים מודרניים.

Joe Medley
Joe Medley
GitHub

תמיכה בדפדפן

  • 25
  • 14
  • 23
  • 7

מקור

מודל האבטחה של האינטרנט מבוסס על מדיניות מקור זהה. לדוגמה, לקוד מ-https://mybank.com חייבת להיות גישה רק לנתונים של https://mybank.com, ואסור ש-https://evil.example.com אף פעם לא יקבל גישה. באופן תיאורטי, כל מקור נשאר מבודד משאר האינטרנט, וכך למפתחים יש ארגז חול בטוח שאפשר להתבסס עליו. עם זאת, בפועל תוקפים מצאו כמה דרכים לחדור למערכת.

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

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

הרכיבים של CSP

כדי להטמיע מדיניות CSP אפקטיבית, צריך לבצע את השלבים הבאים:

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

רשימות היתרים של מקורות

התקפות XSS מנצלות את חוסר היכולת של הדפדפן להבחין בין סקריפט שהוא חלק מהאפליקציה לבין סקריפט שהוחדר באופן זדוני על ידי צד שלישי. לדוגמה, הלחצן Google +1 שבתחתית הדף הזה טוען ומפעיל קוד מ-https://apis.google.com/js/plusone.js בהקשר של המקור של הדף. אנחנו סומכים על הקוד הזה, אבל אי אפשר לצפות שהדפדפן יזהה בעצמו שקוד מ-apis.google.com בטוח להפעלה, ואילו קוד מ-apis.evil.example.com כנראה לא. הדפדפן בשמחה מוריד ומפעיל כל קוד שדף מבקש, ללא קשר למקור.

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

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

Content-Security-Policy: script-src 'self' https://apis.google.com

script-src היא הוראה השולטת בקבוצה של הרשאות שקשורות לסקריפט בדף מסוים. הכותרת 'self' כמקור חוקי אחד לסקריפט ו-https://apis.google.com כמקור אחר. עכשיו הדפדפן יכול להוריד ולהפעיל JavaScript מ-apis.google.com באמצעות HTTPS, וגם מהמקור של הדף הנוכחי, אבל לא מכל מקור אחר. אם תוקף מחדיר קוד לאתר, הדפדפן יוצר הודעת שגיאה ולא מריץ את הסקריפט שהוחדר.

שגיאת מסוף: טעינת הסקריפט 'http://evil.example.com/evil.js' נדחתה מכיוון שהוא מפר את ההוראה הבאה של Content Security Policy: Script-src 'self' https://apis.google.com
במסוף מופיעה הודעת שגיאה כשסקריפט מנסה לפעול ממקור שלא נמצא ברשימת ההיתרים.

המדיניות חלה על מגוון רחב של משאבים

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

הרשימה הבאה מפרטת את שאר ההוראות לגבי משאבים נכון לרמה 2. כבר נוצר מפרט ברמה 3, אבל הוא לא מוטמע ברובו בדפדפנים העיקריים.

base-uri
מגבילה את כתובות ה-URL שיכולות להופיע ברכיב <base> של הדף.
child-src
פירוט של כתובות ה-URL של העובדים ותוכן של מסגרות מוטמעות. לדוגמה, child-src https://youtube.com מאפשר הטמעה של סרטונים מ-YouTube אבל לא ממקורות אחרים.
connect-src
מגבילה את המקורות שאפשר להתחבר אליהם באמצעות XHR, WebSockets ו-EventSource.
font-src
ההגדרה קובעת את המקורות שיכולים להציג גופני אינטרנט. לדוגמה, אפשר לאשר את השימוש בגופני האינטרנט של Google באמצעות font-src https://themes.googleusercontent.com.
form-action
רשימת נקודות הקצה החוקיות לשליחה מתגים מסוג <form>.
frame-ancestors
ההגדרה קובעת את המקורות שבהם אפשר להטמיע את הדף הנוכחי. ההוראה הזו רלוונטית לתגים <frame>, <iframe>, <embed> ו-<applet>. אי אפשר להשתמש בו בתגי <meta> או במשאבי HTML.
frame-src
ההוראה הזו הוצאה משימוש ברמה 2, אבל שוחזרה ברמה 3. אם הוא לא נמצא, הדפדפן יחזור ל-child-src.
img-src
הגדרת המקור שממנו ניתן לטעון תמונות.
media-src
הגבלת המקורות שמורשים להעביר וידאו ואודיו.
object-src
מאפשרת שליטה על Flash ויישומי פלאגין אחרים.
plugin-types
ההגדרה מגבילה את סוגי יישומי הפלאגין שדף יכול להפעיל.
report-uri
ההגדרה קובעת את כתובת ה-URL שהדפדפן שולח אליה דוחות במקרה של הפרה של מדיניות אבטחת תוכן. לא ניתן להשתמש בהוראה הזו בתגי <meta>.
style-src
מגבילה את המקורות שמהם הדף יכול להשתמש בגיליונות סגנונות.
upgrade-insecure-requests
אפשרות לסוכני המשתמש לשכתב סכמות של כתובות URL על ידי שינוי של HTTP ל-HTTPS. ההנחיה הזו מיועדת לאתרים עם מספר גדול של כתובות URL ישנות שצריך לשכתב.
worker-src
הוראה של CSP ברמה 3 שמגבילה את כתובות ה-URL שאפשר לטעון כ-worker, כ-Shared worker או כ-service worker. נכון ליולי 2017, להנחיה הזו יש הטמעות מוגבלות.

כברירת מחדל, הדפדפן טוען את המשאב המשויך מכל מקור ללא הגבלות, אלא אם מגדירים מדיניות עם הוראה ספציפית. כדי לשנות את ברירת המחדל, אפשר לציין הוראת default-src. ההוראה הזו מגדירה את ברירות המחדל לכל הנחיה שלא צוינה שמסתיימת ב--src. לדוגמה, אם מגדירים את default-src לערך https://example.com ולא מציינים הוראת font-src, אפשר לטעון גופנים רק מ-https://example.com.

בהנחיות הבאות לא נעשה שימוש ב-default-src כחלופה. חשוב לזכור שאם ההגדרה תיכשל, הפעולה הזו היא כמו לאפשר את כל הפעולות הבאות:

  • base-uri
  • form-action
  • frame-ancestors
  • plugin-types
  • report-uri
  • sandbox

תחביר בסיסי של CSP

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

script-src https://host1.com https://host2.com

הדוגמה הבאה היא דוגמה למספר הנחיות, במקרה הזה לאפליקציית אינטרנט שטוענת את כל המשאבים שלה מרשת להעברת תוכן ב-https://cdn.example.net, בלי להשתמש בתוכן ממוסגר או ביישומי פלאגין:

Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'

פרטי ההטמעה

דפדפנים מודרניים תומכים בכותרת Content-Security-Policy ללא קידומת. זו הכותרת המומלצת. הכותרות X-WebKit-CSP ו-X-Content-Security-Policy שעשויות להופיע במדריכים באינטרנט הוצאו משימוש.

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

רשימת המקורות של כל הוראה היא גמישה. אפשר לציין מקורות לפי סכמה (data: או https:), או בטווח הספציפי, החל משם מארח בלבד (example.com, שתואם כל מקור במארח הזה: כל סכימה, כל יציאה) ל-URI מלא (https://example.com:443, שתואם רק ל-HTTPS, רק ל-example.com, ורק ליציאה 443). אפשר להשתמש בתווים כלליים לחיפוש, אבל רק כסכמה, ביציאה או במיקום השמאלי ביותר של שם המארח: *://*.example.com:* יתאים לכל תתי-הדומיין של example.com (אבל לא את example.com עצמו), באמצעות כל סכמה, בכל יציאות.

רשימת המקורות מקבלת גם ארבע מילות מפתח:

  • 'none' לא תואם לכלום.
  • 'self' תואם למקור הנוכחי, אך לא לתת-הדומיינים שלו.
  • 'unsafe-inline' מאפשר JavaScript ו-CSS מוטבעים. מידע נוסף זמין במאמר הימנעות מקוד בתוך השורה.
  • 'unsafe-eval' מאפשר מנגנונים של טקסט ל-JavaScript כמו eval. למידע נוסף, קראו את המאמר הימנעות מeval().

מילות המפתח האלה מחייבות מירכאות בודדות. לדוגמה, script-src 'self' (עם מירכאות) מאשר את ההפעלה של JavaScript מהמארח הנוכחי; script-src self (ללא מירכאות) מאפשר JavaScript משרת "self" (ולא מהמארח הנוכחי), סביר להניח שזו לא הייתה הכוונה.

ארגז חול של הדפים שלך

יש עוד הנחיה אחת שכדאי לדבר עליה: sandbox. היא קצת שונה מהאפשרויות שבדקנו, מפני שהיא מגבילה את הפעולות שהדף יכול לבצע ולא על המשאבים שהדף יכול לטעון. אם ההוראה sandbox קיימת, המערכת מתייחסת לדף כאילו הוא נטען בתוך <iframe> עם המאפיין sandbox. יכולות להיות לכך מגוון רחב של השפעות על הדף: אילוץ הדף להוספת מקור ייחודי, ומניעת שליחה של טפסים, בין היתר. זה קצת מעבר להיקף של הדף הזה, אבל אפשר למצוא פרטים מלאים על מאפיינים חוקיים של הרצה בארגז חול בקטע "Sandboxing" במפרט של HTML5.

המטא תג

מנגנון המסירה המועדף של CSP הוא כותרת HTTP. עם זאת, כדאי להגדיר מדיניות בדף ישירות בתגי העיצוב. עשו זאת באמצעות תג <meta> עם מאפיין http-equiv:

<meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'">

לא ניתן להשתמש בהגדרה הזו עבור frame-ancestors, report-uri או sandbox.

נמנעים מהזנת קוד בתוך השורה

הן חזקות כמו רשימות ההיתרים מבוססות-המקור שמשמשות בהוראות CSP, ולכן הן לא יכולות לפתור את האיום הגדול ביותר שנוצר ממתקפות XSS: הזרקת סקריפט מוטבע. אם תוקף יכול להחדיר תג סקריפט שמכיל ישירות מטען ייעודי (payload) זדוני (כמו <script>sendMyDataToEvilDotCom()</script>), לדפדפן אין דרך להבדיל בינו לבין תג של סקריפט מוטבע חוקי. CSP פותרת את הבעיה הזו על ידי חסימה מוחלטת של סקריפט מוטבע.

החסימה הזו כוללת לא רק סקריפטים שמוטמעים ישירות בתגי script, אלא גם גורמים מטפלים באירועים מוטבעים וכתובות URL של javascript:. צריך להעביר את התוכן של תגי script לקובץ חיצוני, ולהחליף javascript: כתובות URL ואת <a ... onclick="[JAVASCRIPT]"> בקריאות addEventListener() מתאימות. לדוגמה, אפשר לשכתב את הפרטים הבאים מתוך:

<script>
    function doAmazingThings() {
    alert('YOU ARE AMAZING!');
    }
</script>
<button onclick='doAmazingThings();'>Am I amazing?</button>

אפשר לומר משהו כמו:

<!-- amazing.html -->
<script src='amazing.js'></script>
<button id='amazing'>Am I amazing?</button>

// amazing.js
function doAmazingThings() {
    alert('YOU ARE AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
    document.getElementById('amazing')
    .addEventListener('click', doAmazingThings);
});

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

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

איך מאשרים באופן זמני סגנונות וסקריפטים מוטבעים

כדי להפעיל סקריפטים וסגנונות מוטבעים, מוסיפים את 'unsafe-inline' כמקור מורשה בהוראה script-src או style-src. ב-CSP ברמה 2 אפשר גם להוסיף סקריפטים ספציפיים מוטבעים לרשימת ההיתרים, באמצעות צופן קריפטוגרפי חד-פעמי (nonce) או גיבוב (hash) בתור המעקב.

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

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
    // Some inline code I can't remove yet, but need to as soon as possible.
</script>

מוסיפים את הצופן החד-פעמי (nonce) להוראה script-src אחרי מילת המפתח nonce-:

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

צריך ליצור מחדש צמתים לכל בקשה בדף, ואי אפשר לנחש אותם.

גיבובים פועלים באופן דומה. במקום להוסיף קוד לתג הסקריפט, צריך ליצור גיבוב SHA של הסקריפט עצמו ולהוסיף אותו להוראה script-src. לדוגמה, אם הדף הכיל את הפרטים הבאים:

<script>alert('Hello, world.');</script>

המדיניות שלכם צריכה לכלול את הפרטים הבאים:

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

הקידומת sha*- מציינת את האלגוריתם שיוצר את הגיבוב. בדוגמה הקודמת השתמשנו ב-sha256-, אבל ב-CSP יש גם תמיכה ב-sha384- וב-sha512-. כשיוצרים את הגיבוב, צריך להשמיט את תגי <script>. שימוש באותיות רישיות וברווחים, כולל רווחים בהתחלה ובסוף.

פתרונות ליצירת גיבובי SHA זמינים בכל מספר שפות. ב-Chrome בגרסה 40 ואילך, אפשר לפתוח את כלי הפיתוח ואז לטעון מחדש את הדף. בכרטיסייה 'מסוף' מוצגות הודעות שגיאה עם גיבוב SHA-256 הנכון לכל אחד מהסקריפטים המוטבעים.

הימנעות מ-eval()

גם אם התוקף לא יכול להחדיר סקריפט באופן ישיר, הוא עדיין יכול להטעות את האפליקציה ולגרום לה להמיר טקסט קלט ל-JavaScript להפעלה ולהפעיל אותו בשמו. eval(), new Function(), setTimeout([string], …) ו-setInterval([string], ...) הם כולם וקטורים שתוקפים יכולים להשתמש בהם כדי להפעיל קוד זדוני באמצעות טקסט שהוחדר. תגובת ברירת המחדל של CSP לסיכון הזה היא לחסום לחלוטין את כל הווקטורים האלה.

יש לכך את ההשפעות הבאות על אופן הבנייה של אפליקציות:

  • צריך לנתח את קובץ ה-JSON באמצעות ה-JSON.parse המובנה, במקום להסתמך על eval. פעולות JSON בטוחות זמינות בכל דפדפן החל מ-IE8.

  • עליכם לשכתב כל קריאה ל-setTimeout או ל-setInterval באמצעות פונקציות מוטבעות במקום מחרוזות. לדוגמה, אם הדף מכיל את הפרטים הבאים:

    setTimeout("document.querySelector('a').style.display = 'none';", 10);

    שכתב אותה כ:

    setTimeout(function () {
    document.querySelector('a').style.display = 'none';
}, 10);
  ```

  • יש להימנע מתבניות בתוך השורה בזמן הריצה. ספריות רבות ליצירת תבניות משתמשות לעיתים קרובות ב-new Function() כדי לזרז את יצירת התבניות בזמן הריצה, וכך להעריך טקסט זדוני. חלק מה-frameworks תומכות ב-CSP מהקופסה, וממשיכות עם מנתח נתונים חזק בהיעדר eval. הוראת ng-csp של AngularJS היא דוגמה טובה לכך. עם זאת, במקום זאת, מומלץ להשתמש בשפה ליצירת תבניות שמציעה הידור מראש, כמו סרגלי יד. הכנה מראש של התבניות יכולה להגביר את חוויית המשתמש אפילו מהר יותר מההטמעה המהירה ביותר בסביבת זמן ריצה, וגם לשפר את אבטחת האתר.

אם eval() או פונקציות אחרות של טקסט ל-JavaScript חיוניות לאפליקציה שלכם, תוכלו להפעיל אותן על ידי הוספת 'unsafe-eval' כמקור מותר בהוראת script-src. אנחנו ממליצים לא לעשות זאת בגלל הסיכון להחדרת קוד.

דיווח על הפרות מדיניות

כדי להודיע לשרת על באגים שעלולים לאפשר החדרה זדונית, אפשר לבקש מהדפדפן POST לדווח על הפרה בפורמט JSON למיקום שצוין בהוראת report-uri:

Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

הדוחות האלה נראים כך:

{
    "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
    }
}

הדוח מכיל מידע שימושי לאיתור הגורם להפרת המדיניות, כולל הדף שבו היא אירעה (document-uri), הדף referrer של הדף, המשאב שהפר את המדיניות של הדף (blocked-uri), ההוראה הספציפית שהוא הפר (violated-directive) והמדיניות המלאה של הדף (original-policy).

דוח בלבד

אם רק התחלתם להשתמש ב-CSP, מומלץ להשתמש במצב דיווח בלבד כדי להעריך את מצב האפליקציה לפני שינוי המדיניות. כדי לעשות זאת, במקום לשלוח את הכותרת Content-Security-Policy, צריך לשלוח כותרת Content-Security-Policy-Report-Only:

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

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

שימוש בעולם האמיתי

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

ווידג'טים של רשתות חברתיות

  • לחצן הלייק של Facebook כולל מספר אפשרויות הטמעה. מומלץ להשתמש בגרסה <iframe> כדי להשאיר אותה בארגז חול משאר האתר. היא צריכה הוראת child-src https://facebook.com כדי לפעול באופן תקין.
  • לחצן הציוץ של X מסתמך על גישה לסקריפט. מעבירים את הסקריפט שהוא מספק לקובץ JavaScript חיצוני ומשתמשים בהוראה script-src https://platform.twitter.com; child-src https://platform.twitter.com.
  • לפלטפורמות אחרות יש דרישות דומות, ואפשר להתייחס אליהן באופן דומה. כדי לבדוק את המשאבים האלה, מומלץ להגדיר default-src של 'none' ולצפות במסוף כדי לבדוק אילו משאבים צריך להפעיל.

כדי להשתמש במספר ווידג'טים, שלב את ההנחיות באופן הבא:

script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com

סגר

באתרים מסוימים, כדאי לוודא שאפשר לטעון רק משאבים מקומיים. בדוגמה הבאה מפתחים מדיניות CSP לאתר בנק. החל ממדיניות ברירת מחדל שחוסמת הכול (default-src 'none').

האתר טוען את כל התמונות, הסגנונות והסקריפטים מ-CDN ב-https://cdn.mybank.net, ומתחבר ל-https://api.mybank.com/ באמצעות XHR כדי לאחזר נתונים. היא משתמשת במסגרות, אבל רק לדפים מקומיים לאתר (ללא מקורות של צד שלישי). האתר ללא Flash, ללא גופנים וללא תוספות. כותרת ה-CSP המגבילה ביותר שאפשר לשלוח היא:

Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'

SSL בלבד

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

Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'

https: צוין ב-default-src, אבל הסקריפט והנחיות הסגנון לא יורשים את המקור הזה באופן אוטומטי. כל הוראה מחליפה את ברירת המחדל של סוג המשאב הספציפי הזה.

פיתוח תקן CSP

Content Security Policy רמה 2 הוא תקן מומלץ של W3C. קבוצת העבודה בנושא אבטחת אפליקציות אינטרנט של W3C מפתחת את האיטרציה הבאה למפרט, Content Security Policy Level 3.

כדי לעקוב אחר הדיון בנוגע לתכונות הבאות, תוכלו לעיין בארכיון של רשימת התפוצהpublic-webappsec@.