Content Security Policy: كيف تعرف أي Directive منع المورد

عندما لا يعمل script أو image أو iframe بسبب CSP، الحل السيئ هو توسيع default-src حتى تختفي الرسالة. CSP تتكون من directives متخصصة، والمتصفح يوضح غالبًا أي واحدة منعت المورد. التشخيص المنهجي يحافظ على أقل سماح بدل كسر السياسة كلها.

ابدأ من Console

اقرأ رسالة violation كاملة: المورد، directive، و source list. default-src يعمل fallback لبعض الأنواع إذا directive الخاصة غائبة. لا تفترض أن script-src هو السبب دائمًا.

حدد نوع المورد

Script و style و img و font و connect و worker و frame لكلها directives ممكنة. XHR/WebSocket عادة تقع تحت connect-src. Service Worker له worker-src أو fallbacks حسب المواصفة.

افحص nonce/hash

ل ـinline code، إضافة 'unsafe-inline' حل واسع. الأفضل nonce per response أو hash للمحتوى الثابت عند ملاءمته. تأكد أن nonce يصل لنفس العنصر ولا يُعاد استخدامه بطريقة غير صحيحة.

استخدم Report-Only أولًا

عند تشديد policy على موقع قائم، Content-Security-Policy-Report-Only يساعد على رؤية ما سيتكسر بدون منع. لكن التقارير قد تحتوي URLs حساسة فتعامل معها بحماية مناسبة.

انتبه لل Redirects

Source مسموح قد redirect إلى host غير مسموح. راقب network chain. السماح host أول لا يعني السماح النهائي في كل directive.

لا توسع السياسة بلا حد

أضف المصدر المحدد الذي يحتاجه التطبيق، وراجع إن كان third-party ضروريًا أصلًا. wildcard واسع أو unsafe-eval يقلل قيمة CSP بشكل كبير.

اختبر CSP على Error Pages وال Routes الثانوية

الصفحة الرئيسية قد تملك سياسة ممتازة بينما 404 أو صفحة Login أو Admin route تُخدم من template مختلف بلا nonce أو بسياسة أوسع. اجمع Content-Security-Policy headers من مجموعة routes أساسية وقارنها. شغل Report-Only عند إدخال سياسة جديدة، ثم صنف violations حسب source ونوع المورد؛ تجاهل ضوضاء extensions الخاصة بالمستخدم ولا تضف مصادر لها إلى السياسة. اختبر كذلك redirects إلى صفحات خطأ لأن CSP قد تتغير بعد الانتقال. هذه المراجعة تمنع أن يكون أضعف route هو الطريق لتجاوز حماية أقوى الصفحة الرئيسية.

راجع nonce مع SSR و Hydration

في تطبيقات SSR، nonce يجب أن يصل إلى scripts التي ينشئها الخادم وأي loader يحتاجه client. اختبر reload مباشرًا و navigation داخل SPA؛ بعض frameworks تعمل في الأولى وتفشل عند hydration أو chunk ديناميكي. لا تحول الحل إلى unsafe-inline. اجعل nonce جزءًا من response context واختبر أن كل request يحصل قيمة مناسبة.

من المثال إلى تطبيق يمكن صيانته

في «Content Security Policy: كيف تعرف أي Directive منع المورد» جرّب الحل على حالة صغيرة ثم أضف failure path واضحًا واختبارًا آليًا يحمي السلوك المتوقع. حدّد contract للمدخلات والمخرجات، وتعامل مع القيم الناقصة قبل الوصول إلى طبقة التنفيذ. إذا كان الحل يتعامل مع API أو ملف أو DOM، أضف logging مختصرًا يوضح المرحلة وكود الخطأ دون بيانات حساسة. بعد ذلك اختبر التوافق مع نسخة سابقة أو بيئة مختلفة. هذه الخطوات تجعل المثال مفيدًا في مشروع حقيقي بدل أن يبقى snippet يعمل فقط في المسار المثالي.