तीसरे पक्ष के क्रॉस-ऑरिजिन रिसॉर्स में, अक्सर ज़रूरत के मुताबिक सीओआरपी हेडर शामिल नहीं होते. अगर क्रेडेंशियल के बिना उनका अनुरोध किया जा सकता है, तो अब उन्हें इस तरह मार्क करके, क्रॉस-ऑरिजिन आइसोलेशन की सुविधा चालू की जा सकती है.
हमने क्रॉस-ऑरिजिन एम्बेडर नीति (सीओईपी) की नई वैल्यू credentialless को शिप किया है. इसकी मदद से, ब्राउज़र ऐसे क्रॉस-ऑरिजिन रिसॉर्स लोड कर सकता है जो क्रॉस-ऑरिजिन रिसॉर्स नीति (सीओआरपी) का इस्तेमाल नहीं करते. इसके लिए, ब्राउज़र कुकी जैसे क्रेडेंशियल के बिना अनुरोध भेजता है. इससे डेवलपर को क्रॉस-ऑरिजिन आइसोलेशन को आसानी से अपनाने में मदद मिलती है.
हमें क्रॉस-ऑरिजिन आइसोलेशन की ज़रूरत क्यों है
कुछ वेब एपीआई, साइड-चैनल हमलों का खतरा बढ़ाते हैं. जैसे, Spectre. इस खतरे को कम करने के लिए, ब्राउज़र ऑप्ट-इन के आधार पर अलग-अलग एनवायरमेंट उपलब्ध कराते हैं. इसे क्रॉस-ऑरिजिन आइसोलेशन कहा जाता है. क्रॉस-ऑरिजिन के अलग-अलग होने पर, वेबपेज में खास सुविधाओं का इस्तेमाल किया जा सकता है. इनमें SharedArrayBuffer,
performance.measureUserAgentSpecificMemory() और बेहतर रिज़ॉल्यूशन वाले सटीक टाइमर शामिल हैं. साथ ही, ऑरिजिन को दूसरे ऑरिजिन से अलग रखा जा सकता है. हालांकि, ऐसा तब तक किया जा सकता है, जब तक वे ऑरिजिन ऑप्ट-इन न कर लें.
क्रॉस-ऑरिजिन आइसोलेशन की सुविधा चालू करने के लिए, वेबपेज को दो एचटीटीपी हेडर भेजने होंगे:
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
क्रॉस-ऑरिजिन आइसोलेट की स्थिति में, सभी क्रॉस-ऑरिजिन रिसॉर्स को सीओआरएस के साथ दिखाया जाना चाहिए या लोड किए जाने के लिए Cross-Origin-Resource-Policy हेडर सेट किया जाना चाहिए.
क्रॉस-ऑरिजिन आइसोलेशन की सुविधा चालू करने से जुड़ी समस्याएं
क्रॉस-ऑरिजिन आइसोलेशन की मदद से, वेबपेजों को बेहतर सुरक्षा मिलती है. साथ ही, इसमें बेहतर सुविधाएं चालू की जा सकती हैं. हालांकि, इसे डिप्लॉय करना मुश्किल हो सकता है. सबसे बड़ी चुनौतियों में से एक, सभी क्रॉस-ऑरिजिन संसाधनों के लिए सीओआरएस या सीओआरपी को चालू करना है. जिन संसाधनों में ये हेडर नहीं हैं उन्हें ब्राउज़र, क्रॉस-ऑरिजिन वाले अलग-थलग किए गए पेज पर लोड नहीं करेगा.
आम तौर पर, क्रॉस-ऑरिजिन रिसॉर्स तीसरे पक्ष से मिलते हैं. ऐसे में, हो सकता है कि वे ज़रूरी हेडर जोड़ने में आसानी न पाएं.
लेकिन अगर हमें पता है कि रिसॉर्स को लोड करना सुरक्षित है, तो क्या होगा? असल में, सिर्फ़ उन संसाधनों को खतरा होता है जिनके लिए क्रेडेंशियल का इस्तेमाल करके अनुरोध किया जाता है. ऐसा इसलिए, क्योंकि उनमें संवेदनशील जानकारी शामिल हो सकती है, जिसे हमलावर अपने दम पर लोड नहीं कर सकता. इसका मतलब है कि जिन संसाधनों के लिए क्रेडेंशियल के बिना अनुरोध किया जा सकता है वे सार्वजनिक तौर पर उपलब्ध होते हैं और उन्हें लोड करना सुरक्षित होता है.
credentialless की मदद से
ऐसे में, COEP: credentialless का इस्तेमाल किया जा सकता है. credentialless, Cross-Origin-Embedder-Policy हेडर के लिए एक नई वैल्यू है. require-corp की तरह ही, यह क्रॉस-ऑरिजिन आइसोलेशन को चालू कर सकता है. हालांकि, बिना सीओआरएस वाले क्रॉस-ऑरिजिन अनुरोधों के लिए CORP:cross-origin हेडर की ज़रूरत के बजाय, उन्हें क्रेडेंशियल (उदाहरण के लिए, कुकी) के बिना भेजा जाता है.
क्रॉस-ऑरिजिन आइसोलेशन को इन दो हेडर की मदद से भी चालू किया जा सकता है:
Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin
इसका मतलब है कि अनुरोध किया गया क्रॉस-ऑरिजिन सर्वर, संवेदनशील संसाधन के साथ जवाब नहीं दे पाएगा. साथ ही, अनुरोध करने वाला व्यक्ति हमेशा यह मान सकता है कि जवाब में सिर्फ़ सार्वजनिक तौर पर उपलब्ध जानकारी शामिल है.
यह तीसरे पक्ष की कुकी का इस्तेमाल बंद करने के ब्राउज़र के प्लान के मुताबिक भी है.
डेमो
इस डेमो में, हेडर के अलग-अलग विकल्प आज़माए जा सकते हैं: https://cross-origin-isolation.glitch.me
अक्सर पूछे जाने वाले सवाल
क्या credentialless एनवायरमेंट में क्रेडेंशियल वाला अनुरोध भेजा जा सकता है?
हां, लेकिन इसके लिए अनुरोध के मोड को बदलना होगा, ताकि रिस्पॉन्स पर सीओआरएस की जांच की जा सके. <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 में आपको मैन्युअल तरीके से रिक्वेस्ट मोड को सीओआरएस पर स्विच करने की ज़रूरत नहीं होती.
क्या credentialless एनवायरमेंट में, खास हेडर के बिना भी क्रॉस-ऑरिजिन iframe लोड किए जा सकते हैं?
नहीं. credentialless एनवायरमेंट में क्रॉस-ऑरिजिन iframes लोड करने के लिए, अब भी require-corp जैसी ही शर्तें लागू होती हैं. iframe दस्तावेज़ों को दो हेडर के साथ दिखाया जाना चाहिए:
Cross-Origin-Embedder-Policy: credentialless(याrequire-corp)Cross-Origin-Resource-Policy: cross-origin
अच्छी बात यह है कि iframes crossorigin="anonymous" को देकर, उन हेडर के बिना क्रॉस-ऑरिजिन iframes लोड करने की अनुमति देने के बारे में चर्चा चल रही है.
इससे क्रॉस-ऑरिजिन iframe, हेडर के बिना लोड किए जा सकेंगे. हालांकि, इनमें क्रेडेंशियल नहीं होंगे.
क्या इस सुविधा को दूसरे ब्राउज़र भी अपनाएंगे?
- Firefox पर ट्रैकिंग से जुड़ी समस्या
- वेबवर्क के लिए पोज़िशन का अनुरोध: कोई सिग्नल नहीं
- W3C टैग रैंकिंग के लिए अनुरोध: मंज़ूरी बाकी है
आगे क्या होने वाला है
क्रॉस-ऑरिजिन आइसोलेशन से जुड़ी अन्य समस्याओं को कम करने के लिए, दो और अपडेट किए जा रहे हैं:
ऊपर बताई गई समस्याओं की वजह से, SharedArrayBuffer में हुए बदलाव को लागू करने के लिए, Chrome के ऑरिजिन ट्रायल के लिए रजिस्टर करने वाले लोगों को यह जानना हो सकता है कि यह ट्रायल कब खत्म होगा. हमने पहले एलान किया था कि इसे Chrome 96 में बंद कर दिया जाएगा. हालांकि, हमने इसे Chrome 106 में बंद करने का फ़ैसला लिया है.
संसाधन
- COOP और COEP का इस्तेमाल करके, अपनी वेबसाइट को "क्रॉस-ऑरिजिन आइसोलेट" करना
- बेहतर सुविधाओं के लिए, आपको "क्रॉस-ऑरिजिन आइसोलेशन" की ज़रूरत क्यों है
- क्रॉस-ऑरिजिन आइसोलेशन चालू करने के लिए गाइड
- Android के लिए Chrome 88 और डेस्कटॉप के लिए Chrome 92 में, SharedArrayBuffer से जुड़े अपडेट
Unsplash पर, Martin Adams की फ़ोटो