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