तीसरे पक्ष की ओर से दिए जाने वाले क्रॉस-ऑरिजिन संसाधनों में अक्सर सही सीओआरपी हेडर शामिल नहीं होते. अगर क्रेडेंशियल के बिना उनका अनुरोध किया जा सकता है, तो अब उन्हें 'क्रॉस-ऑरिजिन आइसोलेशन' के तौर पर मार्क करके चालू किया जा सकता है.
हमने नई क्रॉस-ऑरिजिन एम्बेडर नीति (सीओईपी) की नई वैल्यू भेज दी है
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()
API के लिए, 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 को लोड करने की अनुमति देने के बारे में बातचीत चल रही है. इसके लिए, iframe को crossorigin="anonymous"
देना होगा.
इससे क्रॉस-ऑरिजिन iframe, हेडर के बिना लोड हो जाएंगे, लेकिन इसके बिना
क्रेडेंशियल डालें.
क्या यह सुविधा अन्य ब्राउज़र में भी इस्तेमाल की जाएगी?
- Firefox से जुड़ी ट्रैकिंग से जुड़ी समस्या
- पोज़िशन के लिए Webkit अनुरोध: कोई सिग्नल नहीं
- W3C TAG पोज़िशन के लिए अनुरोध: मंज़ूरी बाकी है
आगे क्या होगा
Google Workspace for Education से जुड़ी दूसरी चुनौतियों को कम करने के लिए, दो अतिरिक्त अपडेट आने वाले हैं क्रॉस-ऑरिजिन आइसोलेशन:
जिन लोगों ने SharedArrayBuffer बदलाव की अवधि बढ़ाने के लिए, Chrome के ऑरिजिन ट्रायल के लिए रजिस्टर किया, तो ऐसा ऊपर बताई गई रुकावटें यह सोच रही होंगी कि इसे कब खत्म किया जाएगा. मूल रूप से हम एलान किया था कि इसे Chrome 96 में बंद कर दिया जाएगा, लेकिन हमने इसे Chrome 106 पर आने से रोक सकते हैं.
संसाधन
- अपनी वेबसाइट को "क्रॉस-ऑरिजिन आइसोलेटेड" बनाना COOP और COEP का इस्तेमाल करके
- आपको "क्रॉस-ऑरिजिन आइसोलेटेड" की ज़रूरत क्यों है बेहतर सुविधाओं के लिए,
- क्रॉस-ऑरिजिन आइसोलेशन को चालू करने के लिए गाइड
- Android Chrome 88 और डेस्कटॉप Chrome 92 में SharedArrayBuffer के अपडेट
मार्टिन एडम्स की खींची गई फ़ोटो तारीख अनस्प्लैश