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

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

Joe Medley

Mike West

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

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

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

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

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

הוראה ברמה 3 של CSP שמגבילה את כתובות ה-URL שאפשר לטעון כ-worker,‏ shared worker או service worker. נכון ליולי 2017, יש ל-directive הזו הטמעות מוגבלות.

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

הדוגמה הבאה כוללת כמה הנחיות, במקרה הזה לאפליקציית אינטרנט שטעינה את כל המשאבים שלה מרשת CDN בכתובת 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. לכך יכולות להיות השפעות רבות על הדף: בין היתר, אפשר לאלץ את הדף לשייך למקור ייחודי ולמנוע שליחת טפסים. זה קצת מעבר להיקף של הדף הזה, אבל אפשר למצוא פרטים מלאים על מאפייני ארגז חול תקינים בקטע 'ארגז חול' במפרט 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: החדרת סקריפט מוטבע. אם תוקף יכול להחדיר תג סקריפט שמכיל ישירות תוכנה זדונית כלשהי (כמו <script>sendMyDataToEvilDotCom()</script>), לדפדפן אין אפשרות להבדיל בינו לבין תג סקריפט לגיטימי שמוטמע בקוד. כדי לפתור את הבעיה הזו, CSP אוסר לחלוטין על סקריפט מוטמע.

האיסור הזה כולל לא רק סקריפטים שמוטמעים ישירות בתגי script, אלא גם פונקציות טיפול באירועים בקוד וגם כתובות URL מסוג javascript:. תצטרכו להעביר את התוכן של תגי script לקובץ חיצוני ולהחליף את כתובות ה-URL מסוג javascript: ו-<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 קריפטוגרפית (מספר שמשמש פעם אחת) או גיבוב, באופן הבא.

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

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

מוסיפים את המזהה החד-פעמי להנחיה 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() לעיתים קרובות כדי לזרז את יצירת התבניות בזמן הריצה, וכך מאפשרים הערכה של טקסט זדוני. יש מסגרות שמספקות תמיכה ב-CSP מובנית, ומשתמשות בניתוח חזק במקרה של חוסר ב-eval. דוגמה טובה לכך היא הוראת ng-csp של AngularJS. עם זאת, מומלץ להשתמש במקום זאת בשפת תבניות שמציעה הידור מראש, כמו Handlebars. הידור מראש של התבניות יכול לשפר את חוויית המשתמש אפילו יותר מההטמעה המהירה ביותר בסביבת זמן הריצה, וגם לשפר את האבטחה של האתר.

אם 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@.