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

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

Joe Medley
Joe Medley
GitHub

التوافق مع المتصفح

  • 25
  • 14
  • 23
  • 7

المصدر

يستند نموذج أمان الويب إلى سياسة المصدر نفسه. على سبيل المثال، يجب أن يتمتع الرمز البرمجي من https://mybank.com بإمكانية الوصول إلى بيانات https://mybank.com فقط، ولا يُسمح أبدًا لـ https://evil.example.com بالوصول. من الناحية النظرية، يتم عزل كل مصدر عن بقية المواقع الإلكترونية، ما يوفّر للمطوّرين وضع حماية آمنًا للدمج فيه. ومع ذلك، من الناحية العملية، وجد المهاجمون العديد من الطرق لتدمير النظام.

على سبيل المثال، تتجاوز هجمات البرمجة النصية على المواقع الإلكترونية (XSS) سياسة المصدر نفسه من خلال خداع موقع إلكتروني لعرض رمز ضار مع المحتوى المقصود. هذه مشكلة كبيرة، حيث يثق المتصفحات في جميع الرموز البرمجية التي تظهر في الصفحة باعتبارها جزءًا قانونيًا من أصل أمان تلك الصفحة. تعد ورقة المعلومات المرجعية XSS مقطعًا عرضيًا قديمًا ولكن تمثيليًا للطرق التي قد يستخدمها المهاجم لانتهاك هذه الثقة عن طريق إدخال رمز ضار. إذا أدخل المهاجم أي رمز على الإطلاق بنجاح، يكون قد اخترق جلسة المستخدم وتمكن من الوصول إلى المعلومات الخاصة.

توضّح هذه الصفحة سياسة أمان المحتوى (CSP) كاستراتيجية للحد من مخاطر هجمات حقن الشيفرة المصدريّة عبر موقع وسيط (XSS) وتأثيرها في المتصفحات الحديثة.

مكوّنات سياسة أمان المحتوى (CSP)

لتنفيذ سياسة أمان محتوى (CSP)، عليك اتّخاذ الخطوات التالية:

  • استخدِم القوائم المسموح بها لإبلاغ العميل بالسلوك المسموح به وغير المسموح به.
  • تعرَّف على التوجيهات المتاحة.
  • تعرّف على الكلمات الرئيسية التي يستخدمونها.
  • يمكنك فرض قيود على استخدام الرمز المضمَّن وeval().
  • أبلِغ خادمك عن انتهاكات السياسة قبل فرضها.

القوائم المسموح بها للمصادر

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

خطأ في وحدة التحكّم: تم رفض تحميل النص البرمجي "http://evil.example.com/evil.js" لأنّه ينتهك توجيه سياسة أمان المحتوى التالي: 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 التي يمكن تحميلها كعامل أو عامل مشترك أو مشغّل خدمات اعتبارًا من يوليو 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+، بينما لا يتوفّر الزرّ 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: وعناوين 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. يتيح لك المستوى 2 من سياسة أمان المحتوى (CSP) أيضًا إضافة نصوص برمجية مضمَّنة محدّدة إلى القائمة المسموح بها باستخدام رقم تعريفي للتشفير (رقم يُستخدم مرة واحدة) أو باستخدام التجزئة على النحو التالي.

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

إذا كانت دوال "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').

يحمّل الموقع الإلكتروني جميع الصور والأنماط والنصوص البرمجية من شبكة توصيل للمحتوى على https://cdn.mybank.net، ويتصل بـ https://api.mybank.com/ باستخدام XHR لاسترداد البيانات. وهو يستخدم إطارات، ولكن فقط للصفحات المحلية على الموقع الإلكتروني (وليست مصادر خارجية). لا يوجد فلاش على الموقع، ولا خطوط، ولا إضافات. عنوان 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@ أرشيفات القائمة البريدية.