لماذا يختلف وضع التقرير فقط عن الوضع الإلزامي في Content Security Policy

By Mirko Peters · 2026-04-23

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

Automatically translated with AI from the original post. Read the English original

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

يشرح هذا المقال سبب أهمية هذين الوضعين، وما يتركانه من أثر على تجربة المتصفح والمستخدم، وكيفية الانتقال من المراقبة البسيطة إلى الحماية الفعلية. وهو موجّه خصيصًا إلى محترفي الأمن والمطورين الذين يعملون ضمن بيئات Microsoft ويريدون ضبط إعداد CSP بالشكل الصحيح، ويغطي التعريفات، وتقنيات التطبيق العملي، وأفضل الممارسات للنشر الآمن والامتثال الذكي.

فهم أوضاع CSP وأثرها

قبل أن تبدأ في إضافة ترويسات CSP، يجب أن تفهم الوضعين الرئيسيين لـ CSP: التقرير فقط والإلزامي. هذان الوضعان أكثر من مجرد إعدادات، فهما يحددان كيفية حماية المتصفحات الحديثة لحدود أمان تطبيقك الويب، أو اكتفائها بمراقبتها. ويؤثر اختيارك مباشرة على مستوى المخاطر في موقعك، وقدرتك على التدقيق، وسلاسة عملية النشر، خاصة في بيئات Microsoft الكبيرة أو الإعدادات متعددة السحابات.

صُممت أوضاع CSP لمنح فرق الويب مرونة. فوضع التقرير فقط هو نقطة الدخول المتدرجة، إذ يتيح لك مراقبة المشكلات دون خوف من كسر شيء لدى المستخدمين عن غير قصد. وهو يدعم تقييم المخاطر، ويساعد في اكتشاف ثغرات السياسة، ويمكنه كشف الشيفرة القديمة أو السلوكيات غير المتوقعة للأطراف الثالثة، مع بقاء تطبيقك يعمل بكامل طاقته.

الوضع الإلزامي هو الحدث الرئيسي، فهو يجعل المتصفح ينفّذ تعليماتك فعليًا. إذا لم يتطابق المحتوى مع سياستك، يُحظر فورًا، مما يقلل سطح الهجوم بشكل آني ضد أمور مثل cross-site scripting أو النصوص البرمجية الخبيثة من أطراف ثالثة. لكن هذا يعني أيضًا أن الأخطاء أو السياسات غير المكتملة قد تُعطّل تطبيقك إذا لم تكن حذرًا في الاختبار والاعتماد.

الفكرة وراء وجود الوضعين معًا بسيطة: دع المطورين وفرق الأمن يحسّنون قواعدهم في البيئة الفعلية قبل الضغط على الزناد. فكّر في الأمر كعجلات التدريب لأمان تطبيقك، ولكن مع خط نهاية تنتقل عنده إلى الإنفاذ الكامل. في القسم التالي، سنتناول بالتفصيل كيف يمنحك وضع التقرير فقط تلك التغذية الراجعة من الواقع، وما الذي يتغير عند دخول الوضع الإلزامي إلى الصورة.

كيف يعمل Content-Security-Policy-Report-Only في إعداد تقارير الانتهاكات

وضع التقرير فقط هو الطريقة التي تتيح لك بها CSP المراقبة من المدرجات قبل أن تنزل إلى الملعب. عند استخدام ترويسة HTTP باسم Content-Security-Policy-Report-Only، فإنك تأمر المتصفح بأن “يراقب الانتهاكات، لكن لا يحظر أي شيء، بل يبلّغ عنها فقط”. بهذه الطريقة تحصل على تدفق من تقارير الانتهاكات تُرسل إلى نقطة النهاية (endpoint) التي تحددها، فتحصل على صورة كاملة عمّا كان سيُحظر لو فُعّلت السياسة.

سترسل المتصفحات تقارير الانتهاكات هذه، غالبًا بصيغة JSON، كلما خالف مورد قواعد CSP لديك. على سبيل المثال، إذا حاولت صفحة تحميل نص برمجي من مصدر غير معتمد، فلن يُحظر أي نص برمجي في وضع التقرير فقط، لكنك ستتلقى تنبيهًا وتفاصيل مثل عنوان URL المخالف، والتوجيه الذي تم انتهاكه، وأحيانًا عينة من الشيفرة المشبوهة.

هذا الوضع لا يقدّر بثمن في تقييمات المخاطر والاختبار الآمن. يمكنك نشر قواعد جديدة عبر مجموعة من تطبيقات الويب، ومراقبة ما يتم تفعيله، وضبط السياسة استنادًا إلى بيانات فعلية لا إلى تخمينات. وإذا كنت تشغّل أنظمة قديمة أو سير عمل تجاريًا حرجًا، فلن تخاطر بتعطل الموقع أو بتلقي مكالمات الدعم بسبب التحرك بسرعة زائدة.

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

كيف يعزز الوضع الإلزامي الأمان

وضع الإنفاذ هو المرحلة التي تتحول فيها سياسة CSP من مجرد اقتراح إلى قاعدة ملزمة. عند استخدام الترويسة Content-Security-Policy، تقوم المتصفحات فعلياً بحظر أي محتوى لا يتطابق مع التوجيهات الخاصة بك، دون تحذيرات، بل بإجراء فوري.

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

تطبيق الإبلاغ باستخدام نقاط نهاية Report-URI وReport-To

إعداد الإبلاغ هو ما يمنح سياسة CSP قوتها الحقيقية، ويجعلها تراقب بعينين مفتوحتين. تتيح لك CSP تحديد نقطة نهاية واحدة أو أكثر (باستخدام report-uri أو report-to) ترسل إليها المتصفحات تقارير الانتهاكات. عند حدوث انتهاك، يجمع المتصفح تفاصيل مثل المورد الذي تم حظره والسياسة التي فشلت، ويرسلها في رسالة JSON أو HTTP POST منظمة إلى نقطة النهاية الخاصة بك.

التوجيه report-uri هو الأسلوب القديم: تحدد عنوان URL، فترسل المتصفحات التقارير إليه مباشرةً. أما report-to فهو الخيار الأحدث والأكثر قوة ومرونة للإبلاغ المتقدم، خاصةً مع توسع دعم المتصفحات لواجهة Reporting API. يعمل report-to مع مجموعة مسمّاة قادرة على التعامل مع أنواع مختلفة من التقارير، ويوفر تحكماً أفضل في التصفية.

عند إعداد نقاط النهاية هذه، يجب تأمينها: استخدم HTTPS، وطبّق ضوابط الوصول، وراقب الارتفاعات غير المتوقعة في عدد التقارير، فقد تشير إلى هجوم أو إلى خلل في السياسة. ولا تنسَ الخصوصية: قد تتضمن التقارير عناوين URL أو مقتطفات من البرامج النصية المخالفة، ما يعني ضرورة تنقيح المعلومات الحساسة قبل تخزينها أو مشاركتها، مع مراعاة أنظمة مثل GDPR وCCPA.

تكمن القوة الحقيقية هنا في الرؤية. فمع إعداد الإبلاغ بشكل صحيح، تحصل على تدفق مباشر يوضح أين تلتقط سياستك الانتهاكات، فتتمكن من التعديل والضبط، والانتقال في النهاية إلى الإنفاذ بأمان ودون مفاجآت. هذا المستوى من المراقبة ضروري سواء كنت تدير تطبيقاً واحداً أو بيئة Microsoft 365 واسعة ومعقدة.

التنقل بين بنية CSP وتوجيهاتها لتصميم سياسة فعّالة

كتابة ترويسة CSP متينة ليست علماً صاروخياً، لكنها تتطلب عناية بالتفاصيل، خاصةً عند التعامل مع تطبيقات معقدة وتكاملات مع خدمات Microsoft السحابية. في الأساس، سياسة CSP هي قائمة منظمة من التوجيهات، يخبر كل منها المتصفح بما هو مسموح وما هو غير مسموح. تُرسل هذه السياسات عبر ترويسات HTTP، وغالباً باسم Content-Security-Policy أو Content-Security-Policy-Report-Only، وتُكتب كسلاسل من القواعد مفصولة بفواصل منقوطة.

يكمن جوهر السياسة في توجيهات أساسية مثل default-src وscript-src وimg-src. يعمل default-src كخيار احتياطي: إذا لم يكن لنوع محدد من المحتوى قاعدة خاصة به، يرجع المتصفح إلى هذه القاعدة. أما script-src وimg-src فيركزان على البرامج النصية والصور، ويتيحان لك التحكم بدقة في المصادر الموثوقة (مثل نطاقاتك، وشبكات CDN الموثوقة، وربما حاوية Azure Blob أو اثنتين).

للصياغة أهمية كبيرة. يسرد كل توجيه القيم المسموح بها: عناوين URL، أو مخططات مثل ‘https:’، أو كلمات مفتاحية مثل ‘self’. إذا سمحت بالبرامج النصية المضمنة (وهو أمر مطلوب أحياناً للشيفرة القديمة)، فقد تحتاج إلى ‘unsafe-inline’، لكن توخَّ الحذر، فهذا يُضعف حمايتك ما لم تستخدم تجزئات البرامج النصية (script hashes) أو القيم العشوائية (nonces) للتحقق الإضافي.

بالنسبة لمحترفي Microsoft، انتبه إلى كيفية حقن خدمات السحابة للتبعيات. تحمّل تطبيقات المؤسسات المعقدة الموارد ديناميكياً، أو تستخدم Service Workers، أو تدمج مزودي خدمات خارجيين. يجب أن توازن سياستك بين الصرامة (من أجل الأمان) والمرونة الكافية لتعمل التطبيقات بشكل سليم. فإذا أتقنت الأساسيات منذ البداية، فستكون مرحلة الاختبار لاحقاً أكثر سلاسة.

أفضل الممارسات للانتقال من وضع التقارير فقط إلى وضع الإنفاذ

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

ابدأ بنشر نهج واسع لكنه معقول في وضع التقارير فقط. اجمع تقارير الانتهاكات، ويُفضَّل أن تجمعها باستخدام لوحات المعلومات أو أدوات التحليلات لإبراز المخالفين المتكررين. يساعدك ذلك على تجاوز الضوضاء وتصفية النتائج الإيجابية الخاطئة والتركيز على المخاطر الحقيقية. وإذا وجدت كمًّا كبيرًا من التقارير الروتينية أو المكررة، وهو أمر شائع، فاضبط تحليلات السجلات لديك أو اكتب نصوصًا برمجية تُرشّح التقارير حسب user agent أو نوع المورد.

بعد انخفاض حجم الانتهاكات وحلّ معظم المشكلات، ابدأ بفرض القواعد تدريجيًا مع متابعة ظهور أي أعطال جديدة. انقل الأقسام عالية المخاطر ومنخفضة الحركة إلى وضع الفرض أولًا وراقبها. وإذا سارت الأمور بسلاسة، فوسّع التطبيق ليشمل بقية المشروع. وثّق التغييرات واحصل على ملاحظات من المطورين وأصحاب المصلحة طوال العملية، خاصةً في تطبيقات Microsoft 365 أو Azure المعقدة حيث تضيف طبقات Conditional Access تعقيدات إضافية. وللاطلاع على استراتيجيات وخطط نشر ذات صلة، يستحق الأمر الاطلاع على هذا الدليل حول مشكلات الثقة في Conditional Access وهذه الحلقة حول أمان الهوية.

لا تقلل أبدًا من أهمية الاختبار. استخدم أدوات المطورين في المتصفح، وأدوات اختبار حالة CSP، وحتى عمليات الفحص الآلي في CI/CD للتأكد من أن نهجك يعمل كما هو متوقع. الهدف النهائي؟ تطبيق محصّن ومتوافق مع المتطلبات ومرن، يحميه نهج جرى صقله في الواقع العملي، لا في الأماني.

أمثلة واقعية على CSP في وضع التقارير فقط والوضع المفروض

لا شيء يوضح CSP مثل الأمثلة الواقعية. في وضع التقارير فقط، قد تستخدم ترويسة مثل: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://csp-report.example.com. يسجّل هذا الإعداد كل انتهاك دون أن يزعج المستخدمين، ما يجعله مثاليًا للاختبار في بيئة الإنتاج دون مخاطر.

في المقابل، إليك نهجًا مفروضًا: Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src 'self'; report-uri https://csp-report.example.com. هنا يوقف المتصفح فعليًا أي نص برمجي أو صورة لا تتوافق مع القواعد، فيحمي المستخدمين من المحتوى غير المعتمد فورًا.

عمليًا، تبدأ المؤسسات بوضع التقارير فقط لتحديد البائعين أو النصوص البرمجية أو الميزات التجارية التي ستتعطل في ظل التقييد الصارم. على سبيل المثال، قد تكتشف بوابة حكومية نصوصًا برمجية قديمة أو شبكة توصيل محتوى تسويقية تُحدث انتهاكات متكررة. فتكرر المؤسسة العملية، وتضيف المزودين الآمنين إلى القائمة البيضاء، ثم تفرض النهج النهائي على مراحل لتقليل الاضطرابات.

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

ملخص الفروق الرئيسية بين وضع التقارير فقط والوضع المفروض

• السلوك: يقتصر وضع التقارير فقط على الإبلاغ عن انتهاكات النهج، ولا يتم حظر أي محتوى. أما الوضع المفروض فيحظر فعليًا كل ما يخالف نهج CSP.
• الغرض: يتيح وضع التقارير فقط اختبار النهج وضبطه دون أي مخاطر على المستخدمين. أما الوضع المفروض فهو للحماية الفعلية، إذ يجعل قواعد الأمان سارية التطبيق.
• الأثر على المستخدمين: وضع التقارير فقط غير مرئي، فلا يلاحظه المستخدمون أبدًا. أما الوضع المفروض فقد يعطّل ميزات أو محتوى إذا لم تختبر قواعدك مسبقًا.
• حالات الاستخدام: وضع التقارير فقط مثالي للنشر التدريجي وتحليل المخاطر وفحوص التوافق مع الأنظمة القديمة. أما الوضع المفروض فهو الخطوة الأخيرة لتحقيق أمان قوي ومتوافق مع المتطلبات.
• الامتثال والمخاطر: يساعد وضع التقارير فقط في المراقبة والتوثيق خلال عمليات التدقيق، بينما يمنع الوضع المفروض خروقات الأمان مباشرةً وفي الوقت الفعلي.