سياسة أمان المحتوى

يمكن أن تقلِّل سياسة أمان المحتوى بشكل كبير من خطر هجمات النصوص البرمجية على المواقع الإلكترونية وتأثيرها في المتصفّحات الحديثة.

يستند نموذج أمان الويب إلى سياسة المصدر نفسه. على سبيل المثال، يجب أن يتمكن رمز 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 في "إطار عمل إدارة المحتوى في خدمة مقارنة الأسعار" إنشاء قائمة مسموح بها لموارد المحتوى الموثوق به، ويطلب من المتصفّح تنفيذ موارد من هذه المصادر فقط أو عرضها. حتى إذا تمكّن المهاجم من العثور على ثغرة لإدخال ملف برمجي، لن يتطابق الملف البرمجي مع القائمة المسموح بها، وبالتالي لن يتم تنفيذه.

نثق في 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، بالإضافة إلى مصدر الصفحة الحالية، ولكن ليس من أي مصدر آخر. إذا أدخل مهاجم رمزًا في موقعك الإلكتروني، يعرض المتصفّح خطأ ولا يُشغّل النص البرمجي الذي تم إدخاله.

تسري السياسة على مجموعة كبيرة من الموارد.

توفّر ميزة "إدارة الخدمات في المحتوى" مجموعة من توجيهات السياسة التي تتيح التحكّم الدقيق في الموارد التي يُسمح للصفحة بتحميلها، بما في ذلك script-src من المثال السابق.

توضِّح القائمة التالية بقية توجيهات الموارد اعتبارًا من المستوى 2. تم وضع مسودة لمواصفات المستوى 3، ولكن لم يتم تنفيذها إلى حد كبير في المتصفّحات الكبرى.

base-uri

يحظر عناوين URL التي يمكن أن تظهر في عنصر <base> في الصفحة.

child-src

تُدرِج عناوين URL للعناصر المشغّلة ومحتوى الإطارات المضمّنة. على سبيل المثال، child-src https://youtube.com يتيح تضمين الفيديوهات من YouTube ولكن ليس من مصادر أخرى.

connect-src

تقييد مصادر البيانات التي يمكنك الاتصال بها باستخدام XHR وWebSocket و 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 أو ملف worker مشترَك أو ملف worker للخدمة اعتبارًا من تموز (يوليو) 2 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 الذي يتطابق مع أي مصدر على ذلك المضيف: أي مخطط وأي منفذ) إلى معرّف الموارد المنتظم المؤهَّل بالكامل (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. يتيح لك المستوى 2 من سياسة CSP أيضًا إضافة نصوص برمجية مضمّنة محدّدة إلى القائمة المسموح بها باستخدام مفتاح تشفير عشوائي (رقم يُستخدَم مرة واحدة) أو تجزئة على النحو التالي:

لاستخدام مفتاح nonce، امنح علامة النص البرمجي سمة 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 hash للنص البرمجي نفسه وأضِفه إلى التوجيه script-src. على سبيل المثال، إذا كانت صفحتك تتضمّن ما يلي:

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

يجب أن تتضمّن سياستك ما يلي:

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

تحدِّد البادئة sha*- الخوارزمية التي تُنشئ التجزئة. يستخدم المثال السابق الرمز sha256-، ولكن يمكن استخدام الرمزَين sha384- وsha512- أيضًا مع CSP. عند إنشاء العلامة، احذف علامات <script>. يجب مراعاة الكتابة بالأحرف اللاتينية الكبيرة والمسافات البيضاء، بما في ذلك المسافات البيضاء البادئة واللاحقة.

تتوفّر حلول لإنشاء تجزئات SHA بأي عدد من اللغات. باستخدام الإصدار 40 من Chrome أو الإصدارات الأحدث، يمكنك فتح "أدوات مطوّري البرامج" ثم إعادة تحميل صفحتك. تعرِض علامة التبويب "وحدة التحكّم" رسائل الخطأ مع تجزئة 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"
    }
}

يحتوي التقرير على معلومات مفيدة للعثور على سبب انتهاكه لسياسة AdSense، بما في ذلك الصفحة التي حدث فيها الانتهاك (document-uri) وreferrer الصفحة ومصادر الانتهاك لسياسة الصفحة (blocked-uri) والتوجيه المعنيّ الذي تم انتهاكه (violated-directive) وسياسة الصفحة الكاملة (original-policy).

إعداد التقارير فقط

إذا كنت قد بدأت للتو استخدام "إطار عمل حماية المحتوى"، ننصحك باستخدام وضع "إعداد التقارير فقط" لتقييم حالة تطبيقك قبل تغيير سياستك. لإجراء ذلك، بدلاً من إرسال عنوان Content-Security-Policy، أرسِل عنوان Content-Security-Policy-Report-Only:

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

لا تحظر السياسة المحدّدة في وضع "إعداد التقارير فقط" الموارد المحظورة، ولكنها تُرسِل تقارير الانتهاكات إلى الموقع الجغرافي الذي تحدّده. يمكنك أيضًا إرسال كلا заголовيَين لفرض سياسة معيّنة أثناء مراقبة سياسة أخرى. هذه طريقة رائعة لاختبار التغييرات في خدمة إدارة المحتوى أثناء فرض سياستك الحالية: يمكنك تفعيل إعداد تقارير لسياسة جديدة، ومراقبة تقارير الانتهاكات وإصلاح أي أخطاء، وعندما تصبح راضيًا عن السياسة الجديدة، ابدأ بفرضها.

الاستخدام في الحياة اليومية

الخطوة الأولى نحو وضع سياسة لتطبيقك هي تقييم الموارد التي يحمّلها. بعد فهم بنية تطبيقك، أنشئ سياسة استنادًا إلى متطلباته. تتناول الأقسام التالية بعض حالات الاستخدام الشائعة وعملية اتخاذ القرار بشأن دعمها وفقًا لإرشادات 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 ل retrieving data. ويستخدم هذا الإطار الصفحات المحلية فقط على الموقع الإلكتروني (بدون استخدام مصادر تابعة لجهات خارجية). لا يتضمّن الموقع الإلكتروني فلاشًا أو خطوطًا أو عناصر إضافية. يليه عنوان 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'

طبقة المقابس الآمنة فقط

في ما يلي مثال على سياسة خدمة المحتوى (CSP) لمشرف منتدى يريد التأكّد من أنّه لا يتم تحميل جميع الموارد على المنتدى إلا باستخدام قنوات آمنة، ولكنه ليس لديه معرفة بالترميز ولا يملك الموارد اللازمة لإعادة كتابة برمجية منتدى تابعة لجهة خارجية مليئة بالنصوص البرمجية والأنماط المضمّنة:

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

على الرغم من تحديد https: في default-src، لا تكتسِب توجيهات النص البرمجي وملف الأسلوب هذا المصدر تلقائيًا. ويؤدّي كل توجيه إلى إلغاء الإعداد التلقائي لهذا النوع المحدّد من الموارد.

تطوير معيار CSP

يُعدّ المستوى 2 من "سياسة أمان المحتوى" معيارًا مقترَحًا من W3C. تعمل مجموعة عمل أمان تطبيقات الويب في W3C على تطوير الإصدار التالي من المواصفة، وهو المستوى 3 من سياسة أمان المحتوى.

لمتابعة المناقشة حول هذه الميزات القادمة، يُرجى الرجوع إلى أرشيف القائمة البريدية public-webappsec@.