تساعد سياسة أمان المحتوى (CSP) في ضمان أن أي محتوى يتم تحميله في الصفحة يثق به مالك الموقع الإلكتروني. يحد مقدمو خدمة CSP من هجمات البرمجة النصية على مستوى المواقع الإلكترونية (XSS) لأنه يمكنهم حظر النصوص البرمجية غير الآمنة التي يُدخِلها المهاجمون. ومع ذلك، يمكن تجاوز سياسة أمان المحتوى بسهولة إذا لم تكن صارمة بدرجة كافية. راجِع المقالة الحدّ من النصوص البرمجية على المواقع الإلكترونية (XSS) باستخدام سياسة صارمة لأمان المحتوى (CSP) للحصول على مزيد من المعلومات. يجمع أداة Lighthouse في هذا المستند "مقدّمي الخدمات لصنّاع المحتوى" (CSP) الذين يتم تطبيقهم على المستند الرئيسي، كما يبلّغ عن المشاكل الواردة من مقيّم CSP في حال تم تجاوزها.
الممارسات المطلوبة لسياسة أمان المحتوى (CSP) غير المسموح بها
نفِّذ الممارسات التالية لضمان عدم تجاوز سياسة أمان المحتوى (CSP). وفي حال كان من الممكن تجاوز سياسة أمان المحتوى (CSP)، ستصدر أداة Lighthouse تحذيرًا عالي الخطورة.
استهداف سياسة أمان المحتوى (CSP) XSS
لاستهداف XSS، يجب أن يتضمّن سياسة CSP توجيهات script-src وobject-src وbase-uri. ويجب أيضًا أن يكون CSP خاليًا من أخطاء البنية.
يحمي script-src وobject-src صفحة من نصوص برمجية غير آمنة ومكوّنات إضافية غير آمنة على التوالي. وبدلاً من ذلك، يمكن استخدام default-src لإعداد سياسة عامة بدلاً من العديد من التوجيهات، بما في ذلك script-src وobject-src.
يمنع base-uri إدخال علامات <base> غير مصرَّح بها يمكن استخدامها لإعادة توجيه جميع عناوين URL النسبية (مثل النصوص البرمجية) إلى نطاق يتحكّم فيه مهاجم.
يستخدم سياسة أمان المحتوى (CSP) nonces أو hashes لتجنب عمليات تجاوز القائمة المسموح بها.
إنّ سياسة أمان المحتوى (CSP) التي تضبط قائمة مسموحًا بها لمتصفِّح script-src تعتمد على افتراض أنّ جميع الردود الواردة من نطاق موثوق به آمنة ويمكن تنفيذها كنصوص برمجية. ومع ذلك، لا ينطبق هذا الافتراض على التطبيقات الحديثة، إذ تسمح بعض الأنماط الشائعة وغير الشائعة، مثل عرض واجهات JSONP واستضافة نُسخ من مكتبة AngularJS، للمهاجمين بالهروب من حدود سياسة أمان المحتوى (CSP).
من الناحية العملية، قد لا يكون من الواضح لمؤلفي التطبيقات أنّ معظم القوائم المسموح بها في script-src يمكن أن يتحايل عليها مهاجم يستخدم خطأ XSS، وبالتالي لا يتم توفير حماية ضئيلة من إدخال النصوص البرمجية. وفي المقابل، لا تواجه النُهج غير المستندة إلى التجزئة هذه المشاكل وتسهّل تطبيق سياسة أكثر أمانًا والحفاظ عليها.
على سبيل المثال، يستخدم هذا الرمز نقطة نهاية JSONP مستضافة على نطاق موثوق به لإدخال نص برمجي يتحكّم فيه مهاجم:
سياسة أمان المحتوى (CSP):
script-src https://trusted.example.com
HTML:
<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>
لتجنُّب تجاوزها، يجب أن تسمح سياسة أمان المحتوى (CSP) بالنصوص البرمجية بشكل فردي باستخدام nonces أو تجزئات واستخدام "strict- Dynamic" بدلاً من قائمة مسموح بها.
اقتراحات إضافية بشأن سياسة أمان المحتوى (CSP) آمنة
نفِّذ الممارسات التالية لتعزيز الأمان والتوافق. في حال عدم اتّباع سياسة أمان المحتوى لأحد الاقتراحات، ستُصدر أداة Lighthouse تحذيرًا متوسط الخطورة.
ضبط إعداد تقارير سياسة أمان المحتوى (CSP)
ستساعدك ضبط وجهة إعداد التقارير في رصد أي أعطال. يمكنك ضبط وجهة إعداد التقارير باستخدام الأمر report-uri أو report-to. الطلب "report-to" غير متوافق حاليًا مع بعض المتصفّحات الحديثة، لذا يوصى باستخدام كليهما أو استخدام report-uri فقط.
إذا كان هناك أي محتوى ينتهك سياسة أمان المحتوى، سيرسل المتصفّح تقريرًا إلى الوجهة التي تم ضبطها. تأكَّد من ضبط تطبيق في هذه الوجهة للتعامل مع هذه التقارير.
تحديد سياسة أمان المحتوى في عنوان HTTP
يمكن تعريف سياسة أمان المحتوى (CSP) في علامة وصفية على النحو التالي:
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
ومع ذلك، يجب تحديد سياسة CSP في عنوان استجابة HTTP إذا أمكن. يؤدي الحقن قبل العلامة الوصفية إلى تجاوز سياسة أمان المحتوى (CSP). بالإضافة إلى ذلك، لا يمكن استخدام frame-ancestors وsandbox وإعداد التقارير في سياسة أمان المحتوى (CSP) للعلامة الوصفية.
التأكُّد من توافق سياسة أمان المحتوى مع الأنظمة القديمة
لا تتوافق بعض المتصفِّحات مع nonces/hashes (خاصية بـ CSP)، لذا ننصح بإضافة unsafe-inline كإجراء احتياطي للمتصفِّحات غير المتوافقة. إذا كان المتصفّح يتوافق مع nonces/hashes، سيتم تجاهل unsafe-inline.
وبالمثل، لا يتوافق strict-dynamic مع كل المتصفحات. ويُنصَح بضبط قائمة مسموح بها كعنصر احتياطي لأي متصفِّحات غير متوافقة. سيتم تجاهل القائمة المسموح بها في المتصفِّحات المتوافقة مع strict-dynamic.
كيفية تطوير سياسة أمان محتوى (CSP) صارمة
في ما يلي مثال على استخدام سياسة CSP صارمة مع سياسة غير مستندة إلى قاعدة بيانات.
سياسة أمان المحتوى (CSP):
script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;
HTML:
<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>
ستكون القيمة random123 من جهة الخادم على مستوى سلسلة base64 في كل مرة يتم فيها تحميل الصفحة. تم تجاهل unsafe-inline وhttps: في المتصفحات الحديثة بسبب nonce وstrict-dynamic. لمزيد من المعلومات عن استخدام سياسة CSP صارمة، يُرجى الاطّلاع على دليل سياسة CSP الصارم.
يمكنك التحقّق من سياسة أمان المحتوى (CSP) لرصد عمليات التجاوز المحتمَلة باستخدام أداة Lighthouse وCSP Evaluator. إذا كنت تريد اختبار سياسة أمان محتوى (CSP) جديدة بدون المخاطرة بتعطُّل الصفحات الحالية، حدِّدها في وضع إعداد التقارير فقط باستخدام Content-Security-Policy-Report-Only كاسم العنوان. سيؤدي ذلك إلى إرسال انتهاكات سياسة أمان المحتوى إلى أي وجهات إعداد تقارير تم ضبطها باستخدام report-to وreport-uri، ولكنها لن تفرض سياسة CSP في الواقع.