शुरू करने से पहले:
- अगर आपको "साइट" और "ऑरिजिन" के बीच के अंतर के बारे में नहीं पता है, तो "same-site" और "same-origin" के बारे में जानकारी लेख पढ़ें.
- स्पेक में मूल स्पेलिंग गलत होने की वजह से,
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 में नेविगेशन और iframe के लिए कौनसा डेटा उपलब्ध कराया जाएगा.
आपकी साइट से किए गए अनुरोध में Referer हेडर में कौनसी जानकारी भेजी जाती है, यह आपके सेट किए गए Referer हेडर से तय होता है.Referrer-Policy
कोई नीति सेट न होने पर, ब्राउज़र की डिफ़ॉल्ट सेटिंग का इस्तेमाल किया जाता है. वेबसाइटें अक्सर ब्राउज़र के डिफ़ॉल्ट सेटिंग का इस्तेमाल करती हैं.
नेविगेशन और iframe के लिए, Referer हेडर में मौजूद डेटा को JavaScript के ज़रिए भी ऐक्सेस किया जा सकता है. इसके लिए, document.referrer का इस्तेमाल करें.
कुछ समय पहले तक, 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के साथ: Referer: 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के साथ: Referer: https://site-one.example/stuff/detail?tag=red
इसका क्या असर होगा?
अन्य ब्राउज़र के साथ हुई बातचीत और Chrome 84 में Chrome के खुद के एक्सपेरिमेंट के आधार पर, उपयोगकर्ताओं को दिखने वाली गड़बड़ियों की संख्या कम होने की उम्मीद है.
सर्वर-साइड लॉगिंग या Analytics, जो पूरे रेफ़रर यूआरएल के उपलब्ध होने पर निर्भर करते हैं उन पर इस जानकारी में कमी का असर पड़ सकता है.
आपको क्या करना होगा?
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जैसे अन्य हेडर और तकनीकों का इस्तेमाल करें. Referer और Referrer-Policy: सबसे सही तरीके देखें. - अगर ज़रूरी हो और आपके उपयोगकर्ताओं को इसके बारे में पता हो, तो किसी नीति के बारे में पार्टनर के साथ मिलकर काम किया जा सकता है.
ऐक्सेस कंट्रोल—जब वेबसाइटें, रेफ़रर का इस्तेमाल करके अन्य ऑरिजिन को अपने संसाधनों का खास ऐक्सेस देती हैं, तो ऐसा हो सकता है. हालांकि, Chrome में हुए बदलाव के बाद भी ऑरिजिन को
Refererहेडर (औरdocument.referrerमें) में शेयर किया जाएगा.
ध्यान दें कि रेफ़रर के मामले में, ज़्यादातर ब्राउज़र एक ही दिशा में आगे बढ़ रहे हैं. ब्राउज़र के डिफ़ॉल्ट और उनके बदलावों के बारे में जानने के लिए, रेफ़रर और रेफ़रर-पॉलिसी: सबसे सही तरीके लेख पढ़ें.
अपनी साइट पर, निजता को बेहतर बनाने वाली नीति लागू करें
आपकी वेबसाइट से शुरू होने वाले अनुरोधों में, Referer को क्या भेजा जाना चाहिए. इसका मतलब है कि आपको अपनी साइट के लिए कौनसी नीति सेट करनी चाहिए?
Chrome में हुए बदलाव को ध्यान में रखते हुए, यह सुझाव दिया जाता है कि आप निजता को बेहतर बनाने वाली नीति सेट करें. जैसे, strict-origin-when-cross-origin या इससे ज़्यादा सख्त नीति.
इससे आपके उपयोगकर्ताओं की सुरक्षा होती है. साथ ही, आपकी वेबसाइट अलग-अलग ब्राउज़र पर एक जैसा काम करती है. ज़्यादातर मामलों में, यह आपको कंट्रोल देता है. इससे आपकी साइट, ब्राउज़र के डिफ़ॉल्ट सेटिंग पर निर्भर नहीं रहती.
नीति सेट करने के बारे में ज़्यादा जानने के लिए, Referrer और Referrer-Policy: सबसे सही तरीके लेख पढ़ें.
Chrome Enterprise के बारे में जानकारी
Chrome की एंटरप्राइज़ नीति
ForceLegacyDefaultReferrerPolicy
उन आईटी एडमिन के लिए उपलब्ध है जो एंटरप्राइज़ एनवायरमेंट में, रेफ़रल देने वाली पुरानी डिफ़ॉल्ट नीति no-referrer-when-downgrade को लागू करना चाहते हैं. इससे एंटरप्राइज़ को अपने ऐप्लिकेशन को टेस्ट करने और अपडेट करने के लिए ज़्यादा समय मिल जाता है.
यह नीति Chrome के वर्शन 88 से हटा दी जाएगी.
सुझाव भेजें
क्या आपको कोई सुझाव/राय देनी है या शिकायत करनी है? Chrome के इंटेंट टू शिप के बारे में सुझाव, शिकायत या राय शेयर करें. इसके अलावा, अपने सवालों को ट्वीट करने के लिए @maudnals पर जाएं.
सभी समीक्षकों को उनके योगदान और सुझाव/राय देने के लिए बहुत-बहुत धन्यवाद. खास तौर पर, कौस्तुभा गोविंद, डेविड वैन क्लीव, माइक वेस्ट, सैम डटन, रोवन मेरवुड, जैक और केसी बास्क को धन्यवाद.