CSP و Permissions-Policy: ما الذي تحميه ترويسات المتصفح وما الذي لا تحميه؟

شرح الفرق بين Content-Security-Policy و Permissions-Policy، وكيف تختبرهما تدريجيًا دون تعطيل موارد الموقع أو الإطارات المضمنة. هذه السياسات طبقة إضافية ضمن أمن التطبيق، ويجب أن تُختبر وفق موارد الموقع الحقيقية.

سياستان متكاملتان وليستا بديلتين

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

ماذا تفعل CSP عند تحميل الصفحة؟

عندما يستقبل المتصفح ترويسة CSP يقيّم طلبات الموارد وفق التعليمات الموجودة فيها. يمكن مثلًا استخدام script-src لتقييد مصادر JavaScript، و style-src للأنماط، و img-src للصور، و connect-src للاتصالات التي تنشئها واجهات البرمجة مثل fetch. قد تعمل default-src كقيمة احتياطية لبعض تعليمات الجلب، لكنها ليست بديلًا عن فهم التعليمات المستقلة مثل frame-ancestors. اختيار مصادر عامة جدًا أو السماح بتنفيذ سكربتات مضمنة بلا ضوابط قد يضعف الحماية. وفي المقابل، منع مصدر حقيقي لخدمة دفع أو خرائط سيؤدي إلى أخطاء يراها المستخدم. السياسة الجيدة تُبنى من جرد الموارد الحقيقية، وليس من قائمة نطاقات متخيلة.

ال ـnonce وال ـhash في سياق JavaScript

تعتمد بعض المواقع على سكربتات مضمنة داخل HTML، وقد تحتاج إلى إعادة هيكلة أو إلى آليات موثقة مثل nonce عشوائي مناسب لكل استجابة أو hash للمحتوى الثابت. لا تضع nonce ثابتًا في قالب وتفترض أنه يمنح مقاومة فعالة للحقن؛ فالقيمة يجب أن تكون غير متوقعة ومربوطة بالاستجابة حسب تصميم السياسة. كذلك لا تستخدم unsafe-inline لتجاوز أخطاء الواجهة بصورة دائمة دون فهم أثره. قد تساعد strict-dynamic في سياسات متقدمة لكنها تحتاج اختبارًا واعيًا لتدفق تحميل السكربتات. لا تجعل إضافة ترويسة أمنية مشروعًا منفصلًا عن بناء HTML؛ فهي جزء من طريقة تحميل الكود وإدارة القوالب والتبعيات.

ما الذي لا تعالجه CSP؟

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

Permissions-Policy في مثال الكاميرا

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

لماذا تتعطل iframe رغم أن الصفحة الأم تعمل؟

قد تحتاج لوحة تحكم إلى تضمين خدمة فيديو أو محرر أو مكالمة عبر iframe. في هذه الحالة تتداخل سياسة المستند الأعلى مع سياسة الإطار ومع خاصية allow في عنصر iframe. إذا منع المستند الأعلى ميزة معينة، فلن يستطيع الإطار عادةً تجاوز هذا المنع بإضافة allow. وفي المقابل قد يحتاج الإطار إلى السماح الصريح بالأصل المناسب حتى تعمل الميزة داخله. يجب التمييز بين منع تحميل الإطار عبر CSP وتعطيل ميزات داخله عبر Permissions-Policy؛ الرسالة التي تظهر في وحدة المطور تختلف، وكذلك الإصلاح. افحص أصل الإطار النهائي، وخاصة إذا كان يعيد التوجيه إلى نطاق آخر، ثم راجع الدعم الفعلي في المتصفح المستهدف.

CSP و CORS ليسا الشيء نفسه

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

نشر تدريجي مع Report-Only

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

خطة اختبار لا تكسر الموقع

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

الحدود والمراجع العملية

تشرح وثائق MDN تفاصيل CSP وتعليمات تحميل الموارد، وتشرح كذلك Permissions-Policy وقواعد السماح والوراثة في الإطارات. لكن دعم التعليمات قد يختلف بين إصدارات المتصفحات؛ راجع جداول التوافق قبل بناء ميزة تعتمد على توجيه جديد. ويمكن الرجوع إلى مقال إيجي تاج «Permissions في المتصفح: كيف تراجعها لكل بروفايل» لفهم أذونات المستخدم من زاوية أخرى. لا تخلط بين إعدادات موقعك التي تصدرها عبر HTTP وبين تفضيلات المتصفح الخاصة بكل مستخدم. والأهم أن تضيف اختبار تراجع دوريًا بعد تحديث مكتبات الواجهة أو مزود الدفع، لأن اعتمادًا جديدًا قد يغيّر قائمة المصادر المطلوبة دون تعديل السياسة تلقائيًا.

المراجع الرسمية: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy ، https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Permissions-Policy. قراءة مكملة: https://egytag.com/ar/articles/permissions-في-المتصفح-كيف-تراجعها-لكل-بروفايل

افحص الترويسات عبر CDN والذاكرة المؤقتة

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