शुरू करने से पहले:
- अगर आपको "site" और "origin" के बीच के अंतर के बारे में नहीं पता, तो "same-site" और "same-origin" के बीच का अंतर लेख पढ़ें.
- स्पेसिफ़िकेशन में मूल गलत स्पेलिंग की वजह से,
Refererहेडर में R नहीं है. JavaScript और DOM मेंReferrer-Policyहेडर औरreferrerको सही तरीके से लिखा गया है.
खास जानकारी
- ब्राउज़र, निजता को बेहतर बनाने वाली डिफ़ॉल्ट रेफ़रर नीतियों के मुताबिक काम कर रहे हैं. अगर किसी वेबसाइट पर कोई नीति सेट नहीं की गई है, तो इन नीतियों को बेहतर बनाया जा रहा है.
- Chrome, 85 में धीरे-धीरे
strict-origin-when-cross-originको डिफ़ॉल्ट नीति के तौर पर चालू करने की योजना बना रहा है. इसका असर इस्तेमाल के उन उदाहरणों पर पड़ सकता है जो किसी दूसरे ऑरिजिन की रेफ़रर वैल्यू पर निर्भर रहते हैं. - यह नया डिफ़ॉल्ट विकल्प है, लेकिन वेबसाइटें अब भी अपनी पसंद की नीति चुन सकती हैं.
- 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 और स्टेबल वर्शन के लिए अगस्त 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 पर ट्वीट करें.
सभी समीक्षकों, कौस्तुभा गोविंद, डेविड वैन क्लेव, माइक वेस्ट, सैम डटन, रोवन मेरेवुड, जेक्सक, और कायस बैस्क के योगदान के लिए धन्यवाद.