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