تحميل الموارد من مصادر متعددة بدون عناوين CORP باستخدام COEP: بدون بيانات اعتماد

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

Eiji Kitamura

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

سبب حاجتنا إلى حظر الوصول من نطاقات أخرى

تزيد بعض واجهات برمجة تطبيقات الويب من خطر الهجمات الجانبية، مثل Spectre: إلى للتخفيف من هذه المخاطر، توفر المتصفحات بيئة معزولة تعتمد على التمكين تسمى حظر الوصول من نطاقات أخرى. من خلال بروتوكول من مصدر خارجي منفصلة، يمكن لصفحة الويب استخدام ميزات خاصة، بما في ذلك SharedArrayBuffer، performance.measureUserAgentSpecificMemory() وموقتات عالية الدقة بدرجة دقة أفضل مع عزل المصدر عن الآخرين ما لم يتم تفعيل ذلك

يجب أن ترسل صفحة الويب عنوانَي HTTP لتفعيل حظر الوصول من نطاقات أخرى:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

يجب عرض جميع الموارد المشتركة المصدر، وذلك من خلال فرض عزل المحتوى من نطاقات أخرى. باستخدام سياسة مشاركة الموارد المتعددة المصادر (CORS) أو ضبط عنوان Cross-Origin-Resource-Policy لتحميلها.

تحديات تفعيل حظر الوصول من نطاقات أخرى

في حين أنّ حظر الوصول من نطاقات أخرى يعزّز أمان صفحات الويب ويتيح إجراء ما يلي: وعلى تمكين ميزات قوية، وإن نشرها يمكن أن يكون صعب. واحدة من أكبر هو الحاجة إلى تفعيل سياسة CORS أو CORP لجميع المصادر المشتركة الموارد. ولن يحمّل المتصفّح الموارد التي لا تحتوي على هذه العناوين على صفحة تحظر الوصول من نطاقات آخرى

يتم عادةً تقديم هذه الموارد متعددة المصادر من قِبل جهات خارجية قد لن يكون من السهل إضافة الرؤوس اللازمة.

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

credentialless للوصول إلى الإنقاذ

وهنا يأتي دور COEP: credentialless. credentialless هي قيمة جديدة. لرأس Cross-Origin-Embedder-Policy. كما هو الحال مع require-corp، يمكن تفعيل حظر الوصول من نطاقات أخرى، ولكن بدلاً من اشتراط CORP:cross-origin لطلبات no-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 متعددة المصادر بدون عناوين ولكن بدون بيانات الاعتماد.

هل سيتم استخدام هذه الميزة في المتصفحات الأخرى؟

الخطوات التالية

هناك تحديثان إضافيان قادمان للتخفيف من التحديات الأخرى المتعلقة حظر الوصول من نطاقات أخرى:

المستخدمون الذين سجّلوا في مرحلة التجربة والتقييم في Chrome لتمديد تغيير SharedArrayBuffer بسبب فقد تتساءل العقبات المذكورة أعلاه عن موعد إنهائه. في الأساس نحن أعلنّا أنّه سيتم إنهاؤها في الإصدار Chrome 96، ولكنّنا قررنا أجِّل هذا إلى Chrome 106.

الموارد

تصوير مارتن آدامز في إلغاء البداية