शुरू करने से पहले:
- अगर आपको "site" और "origin" के बीच का अंतर नहीं पता, तो "same-site" और "same-origin" को समझना लेख पढ़ें.
Refererहेडर में R मौजूद नहीं है, क्योंकि इसकी खास जानकारी में मूल गलत स्पेलिंग है. JavaScript और DOM मेंReferrer-Policyहेडर औरreferrerकी स्पेलिंग सही है.
खास जानकारी
- ब्राउज़र, निजता को बेहतर बनाने वाली डिफ़ॉल्ट रेफ़रल देने वाली नीतियों का इस्तेमाल कर रहे हैं. ऐसा इसलिए किया जा रहा है, ताकि किसी वेबसाइट के लिए कोई नीति सेट न होने पर भी, उपयोगकर्ताओं को अच्छा रिस्पॉन्स मिल सके.
- Chrome,
strict-origin-when-cross-originको धीरे-धीरे 85 वर्शन में डिफ़ॉल्ट नीति के तौर पर चालू करने की योजना बना रहा है. इससे, किसी अन्य ऑरिजिन से रेफ़रर वैल्यू के इस्तेमाल के मामलों पर असर पड़ सकता है. - यह नई डिफ़ॉल्ट नीति है, लेकिन वेबसाइटें अब भी अपनी पसंद की नीति चुन सकती हैं.
- Chrome में बदलाव को आज़माने के लिए,
chrome://flags/#reduced-referrer-granularityपर फ़्लैग को चालू करें. बदलाव को देखने के लिए, इस डेमो को भी देखा जा सकता है. - रेफ़रल देने वाली नीति के अलावा, रेफ़रल देने वालों के साथ ब्राउज़र के काम करने का तरीका बदल सकता है—इसलिए इस पर नज़र बनाए रखें.
क्या बदलाव हो रहा है और क्यों?
एचटीटीपी अनुरोधों में वैकल्पिक Referer हेडर शामिल हो सकता है. इससे पता चलता है कि ऑरिजिन या वेब पेज के यूआरएल से अनुरोध किया गया था. Referer-Policy हेडर से पता चलता है कि Referer हेडर में कौनसा डेटा उपलब्ध कराया जाता है. साथ ही, डेस्टिनेशन के document.referrer में नेविगेशन और iframe के लिए कौनसा डेटा उपलब्ध कराया जाता है.
आपकी साइट से किए गए अनुरोध के Referer हेडर में असल में कौनसी जानकारी भेजी जाती है, यह आपके सेट किए गए Referrer-Policy हेडर से तय होता है.
अगर कोई नीति सेट नहीं है, तो ब्राउज़र की डिफ़ॉल्ट सेटिंग का इस्तेमाल किया जाता है. वेबसाइटें अक्सर ब्राउज़र का डिफ़ॉल्ट मान लेती हैं.
नेविगेशन और iframe के लिए, Referer हेडर में मौजूद डेटा को document.referrer का इस्तेमाल करके, JavaScript से भी ऐक्सेस किया जा सकता है.
हाल ही से पहले तक,
no-referrer-when-downgrade
सभी ब्राउज़र पर डिफ़ॉल्ट रूप से लागू होती रही नीति थी. हालांकि, अब कई ब्राउज़र निजता की बेहतर सेटिंग लागू करने की दिशा में काम कर रहे हैं.
Chrome, अपनी डिफ़ॉल्ट नीति को no-referrer-when-downgrade से
strict-origin-when-cross-origin में बदलने का प्लान बना रहा है. ऐसा वर्शन 85 से किया जा रहा है.
इसका मतलब यह है कि अगर आपकी वेबसाइट के लिए कोई नीति सेट नहीं की गई है, तो Chrome डिफ़ॉल्ट रूप से
strict-origin-when-cross-origin का इस्तेमाल करेगा. ध्यान दें कि आपके पास अब भी अपनी पसंद की नीति सेट करने का विकल्प है.
यह बदलाव सिर्फ़ उन वेबसाइटों पर लागू होगा जिन पर कोई नीति सेट नहीं है.
इस बदलाव का क्या मतलब है?
strict-origin-when-cross-origin ज़्यादा निजता की सुविधा देता है. इस नीति से, क्रॉस-ऑरिजिन अनुरोधों के Referer हेडर में सिर्फ़ ऑरिजिन को भेजा जाता है.
यह ऐसे निजी डेटा को लीक होने से रोकता है जिसे पूरे यूआरएल के दूसरे हिस्सों, जैसे कि पाथ और क्वेरी स्ट्रिंग से ऐक्सेस किया जा सकता है.
उदाहरण के लिए:
क्रॉस-ऑरिजिन अनुरोध, https://site-one.example/stuff/detail?tag=red से https://site-two.example/... पर भेजा गया है:
no-referrer-when-downgradeके साथ: रेफ़रर: https://site-one.example/stuff/detail?tag=red.strict-origin-when-cross-originके साथ: रेफ़रर: https://site-one.example/.
क्या पहले जैसा ही रहता है?
no-referrer-when-downgradeकी तरह,strict-origin-when-cross-originभी सुरक्षित है: एचटीटीपीएस ऑरिजिन (सुरक्षित) से एचटीटीपी ऑरिजिन (असुरक्षित) पर अनुरोध किए जाने पर, कोई रेफ़रर (Refererहेडर औरdocument.referrer) मौजूद नहीं होता. इस तरह, अगर आपकी वेबसाइट एचटीटीपीएस का इस्तेमाल करती है (अगर नहीं, तो इसे प्राथमिकता दें), तो आपकी वेबसाइट के यूआरएल, बिना एचटीटीपीएस वाले अनुरोधों में लीक नहीं होंगे. ऐसा इसलिए, क्योंकि नेटवर्क पर मौजूद कोई भी व्यक्ति इन्हें देख सकता है. इससे आपके उपयोगकर्ताओं को मैन इन द मिडल-अटैक के जोखिम में डाल दिया जाएगा.- उसी ऑरिजिन में,
Refererहेडर की वैल्यू में पूरा यूआरएल होता है.
उदाहरण के लिए: एक ही ऑरिजिन का अनुरोध, https://site-one.example/stuff/detail?tag=red से https://site-one.example/... पर भेजा गया है:
strict-origin-when-cross-originके साथ: रेफ़रर: https://site-one.example/stuff/detail?tag=red
इसका क्या असर होगा?
अन्य ब्राउज़र पर की गई चर्चा और Chrome 84 में किए गए Chrome के एक्सपेरिमेंट के आधार पर, उपयोगकर्ता को दिखने वाली गड़बड़ी के सीमित होने की संभावना है.
सर्वर-साइड लॉगिंग या उपलब्ध आंकड़ों पर निर्भर करता है कि रेफ़रल देने वाला पूरा यूआरएल उपलब्ध है या नहीं. इस वजह से उस जानकारी में जानकारी का स्तर कम होने की वजह से इन चीज़ों पर असर पड़ सकता है.
आपको क्या करना होगा?
Chrome, रेफ़रल देने वाली नई डिफ़ॉल्ट नीति को 85 में रोल आउट करने जा रहा है. बीटा वर्शन के लिए जुलाई 2020 और स्थिर के लिए अगस्त 2020. Chrome की स्थिति की जानकारी में स्थिति देखें.
बदलाव को समझें और उसका पता लगाएं
डिफ़ॉल्ट तौर पर होने वाले नए बदलावों के बारे में जानने के लिए, यह डेमो देखें.
इस डेमो का इस्तेमाल यह पता लगाने के लिए भी किया जा सकता है कि जो Chrome इंस्टेंस चलाया जा रहा है उस पर कौनसी नीति लागू होती है.
बदलाव की जांच करें और पता करें कि क्या इससे आपकी साइट पर असर पड़ेगा
Chrome 81 और इसके बाद के वर्शन में किए गए बदलाव को आज़माने के लिए: Chrome में chrome://flags/#reduced-referrer-granularity पर जाएं और फ़्लैग को चालू करें. इस फ़्लैग के चालू होने पर, बिना नीति वाली सभी वेबसाइटों के लिए strict-origin-when-cross-origin की डिफ़ॉल्ट सेटिंग इस्तेमाल की जाएगी.
अब यह देखा जा सकता है कि आपकी वेबसाइट और बैकएंड कैसे काम करता है.
इसके असर का पता लगाने के लिए एक और तरीका है कि आप यह देख लें कि आपकी वेबसाइट का कोडबेस सर्वर पर आने वाले अनुरोधों के Referer हेडर के ज़रिए या JavaScript में document.referrer से रेफ़रर का इस्तेमाल करता है या नहीं.
अगर आपने अपनी साइट के किसी दूसरे ऑरिजिन से मिले अनुरोधों के रेफ़रर (खास तौर पर पाथ और/या क्वेरी स्ट्रिंग) का इस्तेमाल किया है, तो आपकी साइट की कुछ सुविधाएं काम नहीं कर सकती हैं या अलग तरीके से काम कर सकती हैं. साथ ही, यह ऑरिजिन, ब्राउज़र की डिफ़ॉल्ट रेफ़रर नीति (यानी इसकी कोई नीति सेट नहीं है) का इस्तेमाल करता है.
अगर इसका असर आपकी साइट पर पड़ता है, तो दूसरे तरीकों पर ध्यान दें
अगर आपने अपनी साइट के अनुरोधों का पूरा पाथ या क्वेरी स्ट्रिंग ऐक्सेस करने के लिए, रेफ़रर का इस्तेमाल किया है, तो आपके पास कुछ विकल्प हैं:
- अपनी सीएसआरएफ़ सुरक्षा, लॉगिंग, और इस्तेमाल के दूसरे उदाहरणों के लिए,
OriginऔरSec-fetch-Siteजैसी वैकल्पिक तकनीकों और हेडर का इस्तेमाल करें. रेफ़रर और रेफ़रर-नीति: सबसे सही तरीके देखें. - अगर किसी खास नीति की ज़रूरत हो, तो पार्टनर से संपर्क करें. साथ ही, अपने उपयोगकर्ताओं को इसके बारे में साफ़ तौर पर बताएं.
ऐक्सेस कंट्रोल—जब वेबसाइटें, रेफ़रर का इस्तेमाल अन्य ऑरिजिन को अपने संसाधनों का खास ऐक्सेस देने के लिए करती हैं, तो ऐसा हो सकता है. हालांकि, Chrome के बदलाव के बाद भी ऑरिजिन
Refererहेडर (औरdocument.referrer) में शेयर किया जाएगा.
ध्यान दें कि जब रेफ़रल देने वाले की बात आती है, तब ज़्यादातर ब्राउज़र एक ही तरह से आगे बढ़ रहे होते हैं (रेफ़रर और रेफ़रलकर्ता-नीति: सबसे सही तरीके में ब्राउज़र के डिफ़ॉल्ट और उनके क्रम देखें.
अपनी साइट पर साफ़ तौर पर, निजता को बेहतर बनाने वाली कोई नीति लागू करें
आपकी वेबसाइट से शुरू किए गए अनुरोधों में क्या Referer भेजा जाना चाहिए. जैसे, आपको अपनी साइट के लिए कौनसी नीति सेट करनी चाहिए?
Chrome के बदलाव के बावजूद, निजता को बेहतर बनाने वाली कोई अश्लील नीति सेट करना बेहतर होगा, जैसे कि strict-origin-when-cross-origin या इससे ज़्यादा सख्त नीति.
इससे आपके उपयोगकर्ता सुरक्षित रहते हैं. साथ ही, अलग-अलग ब्राउज़र पर आपकी वेबसाइट का अनुमान लगाने के लिए, वेबसाइट का इस्तेमाल बेहतर तरीके से किया जाता है. ज़्यादातर, इससे आपको कंट्रोल मिलता है —आपकी साइट को ब्राउज़र की डिफ़ॉल्ट सेटिंग पर निर्भर रहने के बजाय, कंट्रोल किया जाता है.
नीति सेट करने के बारे में ज़्यादा जानने के लिए, रेफ़रलकर्ता और रेफ़रल देने वाले-नीति: सबसे सही तरीके देखें.
Chrome Enterprise के बारे में जानकारी
Chrome एंटरप्राइज़ की नीति ForceLegacyDefaultReferrerPolicy उन आईटी एडमिन के लिए उपलब्ध है जो एंटरप्राइज़ एनवायरमेंट में no-referrer-when-downgrade की पिछली डिफ़ॉल्ट रेफ़रर नीति को लागू करना चाहते हैं. इससे एंटरप्राइज़ को अपने ऐप्लिकेशन की जांच करने
और उन्हें अपडेट करने के लिए ज़्यादा समय मिलता है.
यह नीति Chrome 88 में हटा दी जाएगी.
सुझाव/राय दें या शिकायत करें
क्या आपको कोई सुझाव/राय देनी है या शिकायत करनी है? इस बारे में सुझाव/राय दें कि Chrome क्या शिपिंग करना चाहता है. इसके अलावा, @maudnals पर अपने सवाल ट्वीट भी करें.
हमारे सभी समीक्षकों के योगदान और फ़ीडबैक के लिए बहुत-बहुत धन्यवाद. खास तौर पर, कौस्तुभा गोविंद, डेविड वैन क्लीव, माइक वेस्ट, सैम डटन, रोवन मेरवुड, जैक, और केसी बास्क.