لماذا يختلف وضع التقرير فقط عن الوضع المُلزِم في سياسة أمان المحتوى

By Mirko Peters · 2026-04-23

إذا كنت جادًا في أمان الويب، فإن فهم الفرق بين وضعي "التقرير فقط" و"الإنفاذ" في سياسة أمان المحتوى ليس تفصيلًا ثانويًا، بل هو جوهر الموضوع كله…

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

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

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

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

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

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

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

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

كيف يعمل Content-Security-Policy-Report-Only للإبلاغ عن الانتهاكات

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

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

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

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

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

وضع الفرض (Enforced) هو المرحلة التي تتحول فيها سياسة 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 Storage.

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

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

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

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

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

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

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