وفي أغلب الأحيان، لا تتضمن الموارد متعددة المصادر التي تقدمها جهات خارجية عناوين CORP ملائمة. وإذا كان من الممكن طلبها بدون بيانات الاعتماد، يمكنك الآن تفعيل حظر الوصول من نطاقات أخرى من خلال وضع علامة عليها تشير إلى ذلك.
لقد طرحنا القيمة الجديدة لسياسة "مُدمِّج الموارد من مصادر متعددة" (COEP)
credentialless التي تسمح للمتصفّح بتحميل موارد من مصادر متعددة
لا تستخدِم سياسة "موارد المصادر من مصادر متعددة" (CORP)، وذلك من خلال إرسال طلب بدون
بيانات اعتماد، مثل ملفات تعريف الارتباط. يساعد ذلك المطوّرين على اتّباع إجراءات العزل
من مصادر متعددة بسهولة أكبر
سبب الحاجة إلى عزل المحتوى المضمّن من مصادر خارجية
تزيد بعض واجهات برمجة تطبيقات الويب من خطر الهجمات على القنوات الجانبية، مثل Spectre. للحدّ من هذا الخطر، يوفّر المتصفّحات بيئة معزولة تستند إلى الموافقة تُعرف باسم حظر الوصول من نطاقات أخرى. يمكن لصفحة الويب استخدام ميزات خاصة، بما في ذلك SharedArrayBuffer وperformance.measureUserAgentSpecificMemory() والموقّتات العالية الدقة ذات الدقة الأفضل، وذلك في حال عزل المحتوى من مصادر أخرى، ما لم يتم تفعيلها.
يجب أن ترسل صفحة الويب عنوانَي HTTP لتفعيل ميزة "الحظر من مصادر متعددة":
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
في حالة عزل عناوين URL التابعة للنطاق نفسه، يجب عرض جميع الموارد المتعدّدة المصادر
باستخدام CORS أو ضبط عنوان Cross-Origin-Resource-Policy ليتم تحميله.
تحديات تفعيل حظر الوصول من نطاقات أخرى
على الرغم من أنّ عزل مصادر البيانات من مصادر متعددة يمنح صفحات الويب مستوى أمان أفضل وإمكانية تفعيل ميزات فعّالة، إلا أنّ نشره قد يكون صعبًا. ويتمثل أحد أكبر التحديات في شرط تمكين سياسة مشاركة الموارد المتعددة المصادر (CORS) أو "سياسة حقوق الملكية الفكرية" (CORP) لجميع الموارد متعددة المصادر. ولن يحمّل المتصفّح الموارد التي لا تحتوي على هذه العناوين على صفحة تحظر الوصول من نطاقات آخرى.
وعادةً ما تعرِض جهات خارجية هذه الموارد من مصادر متعددة، وقد لا يكون من السهل عليها إضافة العناوين اللازمة.
ولكن ماذا لو علمنا أنّ المورد آمن بما يكفي ليتم تحميله؟ في الواقع، إنّ الموارد الوحيدة المعرضة للخطر هي تلك التي يتم طلبها باستخدام بيانات الاعتماد، لأنّها قد تتضمّن معلومات حسّاسة لا يمكن للمهاجم تحميلها بنفسه. وهذا يعني أنّ الموارد التي يمكن طلبها بدون بيانات اعتماد متاحة بشكل علني وآمنة للتحميل.
credentialless لإنقاذ
وهنا يأتي دور COEP: credentialless. credentialless هي قيمة جديدة
لعنوان Cross-Origin-Embedder-Policy. على غرار require-corp، يمكنه
تفعيل حظر الوصول من نطاقات أخرى، ولكن بدلاً من طلب عنوانCORP:cross-origin
لطلبات الوصول من نطاقات أخرى التي لا تستخدم بروتوكول CORS، يتم إرسالها بدون
بيانات الاعتماد (مثل ملفات تعريف الارتباط).
يمكنك بدلاً من ذلك تفعيل ميزة "حظر الوصول من نطاقات أخرى" باستخدام العنوانين التاليين:
Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin
وهذا يعني أنّ خادم الموارد من مصادر متعددة الذي تمّ طلبه لن يتمكّن من الردّ باستخدام موارد حساسة، ويمكن للمقدّم افتراض أنّ الردّ يحتوي فقط على معلومات متاحة للجميع.
يتوافق ذلك أيضًا مع خطة المتصفّحات للإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية.
عرض توضيحي
يمكنك تجربة خيارات مختلفة للعنوان في هذا الإصدار التجريبي: https://cross-origin-isolation.glitch.me
الأسئلة الشائعة
هل يمكنني إرسال طلب مزوّد ببيانات اعتماد في بيئة credentialless؟
بالتأكيد، ولكن سيؤدي ذلك إلى تغيير وضع الطلب لطلب إجراء عملية التحقّق من سياسة مشاركة الموارد المتعدّدة المصادر (CORS) في الاستجابة. بالنسبة إلى علامات HTML، مثل <audio> و<img> و<link> و<script>
و<video>، ما عليك سوى إلحاق crossorigin="use-credentials" صراحةً لإعلام
المتصفح بإرسال طلبات مستندة إلى بيانات الاعتماد.
على سبيل المثال، حتى إذا كان أحد المستندات على https://www.example.com يتضمّن
العنوان Cross-Origin-Embedder-Policy: credentialless، سترسل الأداة <img
src="https://images.example.com/avatar.png" crossorigin="use-credentials">
طلبًا معتمدًا.
بالنسبة إلى واجهة برمجة التطبيقات fetch()، يمكن استخدام request.mode = 'cors'.
مع توفّر COEP: credentialless، كيف يبقى COEP: require-corp مفيدًا لموقعي الإلكتروني؟
لا تتطلّب COEP: require-corp منك تبديل وضع الطلب يدويًا إلى
CORS إذا كانت ملفات تعريف الارتباط مطلوبة لبعض الموارد الفرعية من مصادر متعددة.
هل يمكنني أيضًا تحميل إطارات iframe من مصادر متعددة بدون رؤوس خاصة في بيئة credentialless؟
لا، لا يزال تحميل إطارات iframe من مصادر مختلفة في بيئة credentialless يتطلّب الشروط نفسها التي يتطلّبها require-corp. يجب عرض مستندات iframe باستخدام عنوانَين:
-
Cross-Origin-Embedder-Policy: credentialless(أوrequire-corp) Cross-Origin-Resource-Policy: cross-origin
والخبر السار هو أنّ هناك مناقشة جارية حول السماح بتحميل إطارات iframe من مصادر متعددة بدون هذه الرؤوس من خلال منح إطارات iframe crossorigin="anonymous".
سيسمح ذلك بتحميل إطارات iframe من مصادر متعددة بدون رؤوس ولكن بدون
بيانات الاعتماد.
هل ستتوفّر هذه الميزة في متصفّحات أخرى؟
- مشكلة تتبُّع في Firefox
- طلب Webkit للموضع: ما مِن إشارة
- علامة W3C طلب موضع الإعلان: في انتظار المراجعة
الخطوات التالية
هناك تحديثان إضافيان قيد الإصدار للتخفيف من التحديات الأخرى المرتبطة بميزة العزل المشترك المصدر:
قد يتساءل المستخدمون الذين سجّلوا في الإصدار التجريبي من Chrome لتوسيع نطاق تغيير SharedArrayBuffer بسبب العقبات المذكورة أعلاه عن موعد إنهاء هذا الإصدار. وقد أعلنّا في البداية أنّه سيتم إنهاؤها في الإصدار Chrome 96، ولكننا قررنا تأجيلها إلى الإصدار Chrome 106.
الموارد
- جعل موقعك الإلكتروني "معزولاً عن مصادر متعددة" باستخدام السياستَين "COOP" و"COEP"
- سبب الحاجة إلى "حظر الوصول من نطاقات أخرى" للحصول على ميزات فعّالة
- دليل تفعيل حظر الوصول من نطاقات أخرى
- تحديثات SharedArrayBuffer في الإصدار 88 من نظام التشغيل Android والإصدار 92 من Chrome لأجهزة الكمبيوتر المكتبي
صورة لمارتن آدامز على Unsplash