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