रेफ़रर और रेफ़रल देने वाली नीति के सबसे सही तरीके

Maud Nalpas

इस पेज पर, रेफ़रल देने वाले से जुड़ी नीति सेट करने और आने वाले अनुरोधों में रेफ़रर का इस्तेमाल करने के सबसे सही तरीके बताए गए हैं.

खास जानकारी

• क्रॉस-ऑरिजिन की जानकारी लीक होने से, वेब इस्तेमाल करने वालों की निजता को नुकसान पहुंचता है. सुरक्षा के लिए, रेफ़रर की नीति से आपको मदद मिल सकती है.
• strict-origin-when-cross-origin की रेफ़रर नीति सेट करें. यह, रेफ़रर की ज़्यादातर उपयोगिता को सुरक्षित रखता है. साथ ही, इससे डेटा के क्रॉस-ऑरिजिन के लीक होने के जोखिम को भी कम किया जाता है.
• क्रॉस-साइट अनुरोध जालसाज़ी (सीएसआरएफ़) से सुरक्षा के लिए, रेफ़रर का इस्तेमाल न करें. इसके बजाय, सीएसआरएफ़ टोकन और अन्य हेडर का इस्तेमाल सुरक्षा को और बेहतर बनाने के लिए करें.

ध्यान दें:

• अगर आपको "site" और "origin" के बीच का अंतर नहीं पता, तो "same-site" और "same-origin" को समझना) देखें.
• मूल स्पेसिफ़िकेशन में गलत स्पेलिंग होने की वजह से, Referer हेडर में R मौजूद नहीं है. JavaScript और DOM में Referrer-Policy हेडर और referrer को सही तरीके से लिखा गया है.

रेफ़रर और रेफ़रर-नीति 101

एचटीटीपी अनुरोधों में एक वैकल्पिक Referer हेडर शामिल किया जा सकता है. इससे उस ऑरिजिन या वेब पेज के यूआरएल की जानकारी मिलती है जिससे अनुरोध किया गया था. Referrer-Policy हेडर से पता चलता है कि Referer हेडर में कौनसा डेटा उपलब्ध कराया जाता है.

यहां दिए गए उदाहरण में, Referer हेडर में site-one पर मौजूद उस पेज का पूरा यूआरएल शामिल है जिससे अनुरोध किया गया था.

रेफ़रर हेडर के साथ एचटीटीपी अनुरोध.

Referer हेडर अलग-अलग तरह के अनुरोधों में मौजूद हो सकता है:

• नेविगेशन के अनुरोध, जब कोई उपयोगकर्ता किसी लिंक पर क्लिक करता है.
• सबरिसॉर्स के अनुरोध, जब कोई ब्राउज़र किसी पेज की ज़रूरत के हिसाब से इमेज, iframe, स्क्रिप्ट, और अन्य रिसॉर्स का अनुरोध करता है.

नेविगेशन और iframe के लिए, document.referrer का इस्तेमाल करके भी JavaScript से इस डेटा को ऐक्सेस किया जा सकता है.

Referer की वैल्यू के ज़रिए बहुत कुछ सीखा जा सकता है. उदाहरण के लिए, कोई Analytics सेवा उनका इस्तेमाल यह पता लगाने के लिए कर सकती है कि site-two.example पर 50% विज़िटर social-network.example से आए. हालांकि, जब Referer सभी ऑरिजिन में पाथ और क्वेरी स्ट्रिंग के साथ पूरा यूआरएल भेजा जाता है, तो इससे उपयोगकर्ता की निजता को खतरा हो सकता है और सुरक्षा को खतरा हो सकता है:

पूरे यूआरएल का इस्तेमाल करने से, उपयोगकर्ता की निजता और सुरक्षा पर असर पड़ सकता है.

#1 से #5 तक के यूआरएल में निजी जानकारी और कभी-कभी संवेदनशील या पहचान बताने वाली जानकारी होती है. इन तरीकों को ऑफ़लाइन इस्तेमाल करने से वेब इस्तेमाल करने वालों की निजता पर असर पड़ सकता है.

यूआरएल #6 एक क्षमता यूआरएल है. अगर टारगेट किए गए उपयोगकर्ता के अलावा, किसी और व्यक्ति को यह मैसेज मिलता है, तो नुकसान पहुंचाने वाला कोई व्यक्ति, इस उपयोगकर्ता के खाते को कंट्रोल कर सकता है.

यह तय करने के लिए कि आपकी साइट से अनुरोधों के लिए कौनसा रेफ़रर डेटा उपलब्ध कराया जाए, रेफ़रल देने वाली नीति सेट की जा सकती है.

कौनसी नीतियां उपलब्ध हैं और वे किस तरह अलग हैं?

आठ नीतियों में से किसी एक को चुना जा सकता है. नीति के हिसाब से, Referer हेडर (और document.referrer) से मिलने वाला डेटा यह हो सकता है:

• कोई डेटा नहीं (कोई Referer हेडर मौजूद नहीं है)
• सिर्फ़ ऑरिजिन
• पूरा यूआरएल: ऑरिजिन, पाथ, और क्वेरी स्ट्रिंग

रेफ़रर से जुड़े डेटा के उदाहरण.

कुछ नीतियों को इस तरह से डिज़ाइन किया गया है कि ये context: क्रॉस-ऑरिजिन या एक ही ऑरिजिन के लिए किए गए अनुरोध के आधार पर अलग-अलग काम करें. भले ही, अनुरोध का डेस्टिनेशन, ऑरिजिन जितना ही सुरक्षित हो या दोनों. इससे अपनी साइट में रेफ़रर की संख्या को बनाए रखते हुए, अलग-अलग ऑरिजिन या कम सुरक्षित ऑरिजिन पर शेयर की जाने वाली जानकारी को सीमित किया जा सकता है.

इस टेबल में दिखाया गया है कि रेफ़रर नीतियां, रेफ़रर हेडर और document.referrer से मिलने वाले यूआरएल डेटा को कैसे सीमित करती हैं:

नीति का दायरा	नीति का नाम	रेफ़रर: कोई डेटा नहीं है	रेफ़रर: सिर्फ़ ऑरिजिन	रेफ़रर: पूरा यूआरएल
इसमें अनुरोध के संदर्भ को शामिल नहीं किया गया	no-referrer	देखें
	origin		देखें
	unsafe-url			देखें
सुरक्षा को ध्यान में रखकर बनाया गया	strict-origin	एचटीटीपीएस से एचटीटीपी पर अनुरोध	एचटीटीपीएस से एचटीटीपीएस या एचटीटीपी से एचटीटीपी पर अनुरोध
	no-referrer-when-downgrade	एचटीटीपीएस से एचटीटीपी पर अनुरोध		एचटीटीपीएस से एचटीटीपीएस या एचटीटीपी से एचटीटीपी पर अनुरोध
निजता को ध्यान में रखकर बनाया गया	origin-when-cross-origin		क्रॉस-ऑरिजिन अनुरोध	एक ही ऑरिजिन वाला अनुरोध
	same-origin	क्रॉस-ऑरिजिन अनुरोध		एक ही ऑरिजिन वाला अनुरोध
निजता और सुरक्षा को ध्यान में रखकर बनाया गया	strict-origin-when-cross-origin	एचटीटीपीएस से एचटीटीपी पर अनुरोध	क्रॉस-ऑरिजिन अनुरोध एचटीटीपीएस से एचटीटीपीएस पर या एचटीटीपी से एचटीटीपी पर	एक ही ऑरिजिन वाला अनुरोध

एमडीएन, नीतियों और व्यवहार के उदाहरणों की पूरी सूची उपलब्ध कराता है.

रेफ़रल देने वाली नीति सेट करते समय इन बातों का ध्यान रखें:

• स्कीम (एचटीटीपीएस बनाम एचटीटीपी) को (strict-origin, no-referrer-when-downgrade, और strict-origin-when-cross-origin) लागू करने वाली सभी नीतियां, एक एचटीटीपी ऑरिजिन से दूसरे एचटीटीपी ऑरिजिन पर भेजे जाने वाले अनुरोधों को एचटीटीपीएस ऑरिजिन से किसी अन्य एचटीटीपी ऑरिजिन पर भेजे जाने वाले अनुरोधों की तरह ही देखती हैं. भले ही, एचटीटीपी कम सुरक्षित हो. ऐसा इसलिए है, क्योंकि इन नीतियों के तहत, यह बात सबसे ज़्यादा मायने रखती है कि सुरक्षा से जुड़ी किसी समस्या को डाउनग्रेड किया जाता है या नहीं. इसका मतलब यह है कि अनुरोध किए जाने पर, डेटा को एन्क्रिप्ट (सुरक्षित) किए गए ऑरिजिन के डेटा को एन्क्रिप्ट (सुरक्षित) न किए गए डेटा में दिखाया जा सकता है. जैसे, एचटीटीपीएस → एचटीटीपी अनुरोधों में. एचटीटीपी → एचटीटीपी अनुरोध को पूरी तरह से एन्क्रिप्ट (सुरक्षित) नहीं किया गया है. इसलिए, इसे डाउनग्रेड नहीं किया जा सकता.
• अगर कोई अनुरोध सेम-ऑरिजिन के लिए है, तो इसका मतलब है कि स्कीम (एचटीटीपीएस या एचटीटीपी) एक ही है. इसलिए, सुरक्षा को डाउनग्रेड नहीं किया जा सकता.

ब्राउज़र में डिफ़ॉल्ट रेफ़रर नीतियां

अक्टूबर 2021 तक का डेटा

अगर कोई रेफ़रर नीति सेट नहीं है, तो ब्राउज़र अपनी डिफ़ॉल्ट नीति इस्तेमाल करता है.

ब्राउज़र	डिफ़ॉल्ट Referrer-Policy / व्यवहार
Chrome	डिफ़ॉल्ट वैल्यू strict-origin-when-cross-origin है.
Firefox	डिफ़ॉल्ट वैल्यू strict-origin-when-cross-origin है. वर्शन 93 से, सख्त ट्रैकिंग सुरक्षा और निजी ब्राउज़िंग के उपयोगकर्ताओं के लिए, क्रॉस-साइट अनुरोधों के लिए, कम पाबंदी वाली रेफ़रर नीतियों no-referrer-when-downgrade, origin-when-cross-origin, और unsafe-url को अनदेखा किया जाता है. इसका मतलब है कि क्रॉस-साइट अनुरोधों के लिए, रेफ़र करने वाले को हमेशा छोटा किया जाता है, भले ही वेबसाइट की नीति कुछ भी हो.
Edge	डिफ़ॉल्ट वैल्यू strict-origin-when-cross-origin है.
Safari	डिफ़ॉल्ट तौर पर, यह strict-origin-when-cross-origin के जैसा ही होता है, लेकिन इसमें कुछ खास अंतर होते हैं. ज़्यादा जानकारी के लिए, प्रिवेंशन ट्रैकिंग को रोकना देखें.

रेफ़रर नीति सेट करने के सबसे सही तरीके

मकसद: निजता बनाए रखने की नीति को साफ़ तौर पर सेट करें, जैसे कि strict-origin-when-cross-origin या ज़्यादा सख्त.

आपकी साइट पर रेफ़रल देने वाली नीतियां सेट करने के कई तरीके हैं:

• एचटीटीपी हेडर के तौर पर
• एचटीएमएल में
• हर अनुरोध के आधार पर JavaScript से

अलग-अलग पेजों, अनुरोधों या एलिमेंट के लिए, अलग-अलग नीतियां सेट की जा सकती हैं.

एचटीटीपी हेडर और मेटा एलिमेंट, दोनों ही पेज लेवल होते हैं. किसी एलिमेंट की असरदार नीति तय करने का प्राथमिकता क्रम इस तरह है:

1. एलिमेंट के लेवल पर नीति
2. पेज स्तर नीति
3. ब्राउज़र की डिफ़ॉल्ट सेटिंग

उदाहरण:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

इमेज का अनुरोध no-referrer-when-downgrade नीति के साथ किया जाता है. इस पेज से मिलने वाले दूसरे सभी सबरिसॉर्स के अनुरोध भी strict-origin-when-cross-origin नीति के मुताबिक होते हैं.

रेफ़रर नीति कैसे देखें?

securityheaders.com की मदद से यह पता लगाया जा सकता है कि कोई साइट या पेज किस नीति का इस्तेमाल कर रहा है.

किसी खास अनुरोध के लिए इस्तेमाल की गई रेफ़रर नीति देखने के लिए, Chrome, Edge या Firefox में डेवलपर टूल का इस्तेमाल भी किया जा सकता है. यह लिखते समय, Safari Referrer-Policy हेडर नहीं दिखाता, लेकिन भेजा गया Referer दिखाता है.

Chrome DevTools के नेटवर्क पैनल में एक अनुरोध चुना गया है.

आपको अपनी वेबसाइट के लिए कौनसी नीति सेट करनी चाहिए?

हमारा सुझाव है कि आप निजता बनाए रखने की बेहतर नीति सेट करें. जैसे, strict-origin-when-cross-origin या इससे ज़्यादा सख्त नीति.

"साफ़ तौर पर" क्यों?

अगर आप रेफ़रर नीति सेट नहीं करते हैं, तो ब्राउज़र की डिफ़ॉल्ट नीति का इस्तेमाल किया जाएगा. असल में, वेबसाइटें अक्सर ब्राउज़र की डिफ़ॉल्ट नीति को मान लेती हैं. हालांकि, यह सही नहीं है, क्योंकि:

• अलग-अलग ब्राउज़र की डिफ़ॉल्ट नीतियां अलग-अलग होती हैं. इसलिए, अगर आपको ब्राउज़र की डिफ़ॉल्ट नीतियां इस्तेमाल करनी हैं, तो आपकी साइट सभी ब्राउज़र के हिसाब से सही व्यवहार नहीं करेगी.
• ब्राउज़र, strict-origin-when-cross-origin जैसे सख्त डिफ़ॉल्ट सेटिंग का इस्तेमाल कर रहे हैं. साथ ही, क्रॉस-ऑरिजिन अनुरोधों के लिए, रेफ़रर में काट-छांट करने जैसे तरीके भी अपना रहे हैं. ब्राउज़र की डिफ़ॉल्ट सेटिंग में बदलाव करने से पहले, निजता-बढ़ाने वाली नीति में साफ़ तौर पर ऑप्ट-इन करने से, आपको कंट्रोल मिलता है. साथ ही, ज़रूरत पड़ने पर टेस्ट करने में मदद मिलती है.

strict-origin-when-cross-origin (या इससे ज़्यादा सख्त) क्यों?

आपके पास ऐसी नीति होनी चाहिए जो सुरक्षित हो, निजता की सुरक्षा करती हो, और काम की हो. "काम की है" का मतलब इस बात पर निर्भर करता है कि आपको रेफ़रर से क्या चाहिए:

• सुरक्षित: अगर आपकी वेबसाइट पर एचटीटीपीएस का इस्तेमाल किया जाता है (अगर ऐसा नहीं है, तो इसे प्राथमिकता दें), तो आपको गैर-एचटीटीपीएस अनुरोधों में अपनी वेबसाइट के यूआरएल लीक नहीं करने होंगे. डेटा लीक होने की वजह से, नेटवर्क पर मौजूद कोई भी व्यक्ति इन्हें देख सकता है. इससे आपके उपयोगकर्ताओं पर आम तौर पर होने वाले हमले हो सकते हैं. no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer, और strict-origin नीतियों से इस समस्या को हल किया जा सकता है.
• निजता बेहतर बनाने की सुविधा: क्रॉस-ऑरिजिन अनुरोध के लिए, no-referrer-when-downgrade पूरा यूआरएल शेयर करता है. इससे निजता से जुड़ी समस्याएं हो सकती हैं. strict-origin-when-cross-origin और strict-origin सिर्फ़ ऑरिजिन शेयर करते हैं और no-referrer किसी भी तरह की जानकारी शेयर नहीं करते. इससे आपके पास strict-origin-when-cross-origin, strict-origin, और no-referrer जैसे ऐप्लिकेशन की निजता को बेहतर बनाने के विकल्प हैं.
• काम की है: no-referrer और strict-origin कभी भी पूरा यूआरएल शेयर नहीं करते, यहां तक कि एक ही ऑरिजिन वाले अनुरोधों के लिए भी. अगर आपको पूरा यूआरएल चाहिए, तो strict-origin-when-cross-origin एक बेहतर विकल्प है.

इन सब बातों का मतलब है कि आम तौर पर strict-origin-when-cross-origin आपके लिए सही विकल्प है.

उदाहरण: strict-origin-when-cross-origin नीति सेट करना

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

या सर्वर-साइड, उदाहरण के लिए एक्सप्रेस में:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

अगर strict-origin-when-cross-origin (या इससे ज़्यादा सख्त) आपके इस्तेमाल के सभी उदाहरणों के लिए उपलब्ध नहीं है, तो क्या होगा?

इस मामले में, प्रोग्रेसिव तरीका अपनाएं: अपनी वेबसाइट के लिए strict-origin-when-cross-origin जैसी सुरक्षा नीति सेट करें. साथ ही, ज़रूरत पड़ने पर खास अनुरोधों या एचटीएमएल एलिमेंट के लिए ज़्यादा अनुमति वाली नीति सेट करें.

उदाहरण: एलिमेंट के लिए नीति

index.html:

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

Safari/WebKit, क्रॉस-साइट के अनुरोधों के लिए, document.referrer या Referer हेडर को कैप कर सकता है. जानकारी देखें.

उदाहरण: अनुरोध के लेवल पर नीति

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

आपको और किन बातों का ध्यान रखना चाहिए?

आपकी नीति आपकी वेबसाइट और इस्तेमाल के उदाहरण पर निर्भर होनी चाहिए, जैसा आप, आपकी टीम, और आपकी कंपनी तय करती है. अगर कुछ यूआरएल में पहचान से जुड़ी या संवेदनशील जानकारी मौजूद है, तो सुरक्षा के लिए नीति सेट करें.

चेतावनी: ऐसा डेटा जो आपको संवेदनशील नहीं लगता, वह आपके उपयोगकर्ताओं के लिए संवेदनशील हो सकता है. यह भी हो सकता है कि वह ऐसा डेटा न हो जो उनकी ज़रूरत के मुताबिक हो या क्रॉस-ऑरिजिन को बिना किसी सूचना के लीक कर दे.

अनुरोधों के लिए सबसे सही तरीके

अगर आपकी साइट आने वाले अनुरोधों के रेफ़रर यूआरएल का इस्तेमाल करती है, तो क्या करना चाहिए, इसके बारे में यहां कुछ दिशा-निर्देश दिए गए हैं.

उपयोगकर्ताओं के डेटा की सुरक्षा करें

Referer में निजी, निजी या पहचान ज़ाहिर करने वाला डेटा शामिल हो सकता है. इसलिए, पक्का करें कि आप इस डेटा को निजी डेटा के तौर पर इस्तेमाल करें.

आने वाले रेफ़रर {referer-can-change} बदल सकते हैं

क्रॉस-ऑरिजिन अनुरोधों के लिए, रेफ़रर का इस्तेमाल करने की कुछ सीमाएं हैं:

• अगर अनुरोध करने वाले व्यक्ति को लागू करने के तरीके पर आपका कोई कंट्रोल नहीं है, तो आपको मिलने वाले Referer हेडर (और document.referrer) के बारे में अनुमान नहीं लगाया जा सकता. अनुरोध करने वाला व्यक्ति, किसी भी समय no-referrer नीति पर स्विच कर सकता है. इसके अलावा, वह आम तौर पर, पहले इस्तेमाल की गई नीति से ज़्यादा सख्त नीति पर स्विच कर सकता है. इसका मतलब है कि आपको Referer से पहले के मुकाबले कम डेटा मिलता है.
• डिफ़ॉल्ट रूप से, ब्राउज़र तेज़ी से रेफ़रर-नीति strict-origin-when-cross-origin का इस्तेमाल करते हैं. इसका मतलब है कि अगर भेजने वाले की साइट पर कोई नीति सेट नहीं की गई है, तो हो सकता है कि अब आपको क्रॉस-ऑरिजिन वाले अनुरोधों में, पूरे रेफ़रर यूआरएल के बजाय सिर्फ़ ऑरिजिन की जानकारी मिले.
• ब्राउज़र, Referer को मैनेज करने का तरीका बदल सकते हैं. उदाहरण के लिए, कुछ ब्राउज़र डेवलपर उपयोगकर्ता की निजता को सुरक्षित रखने के लिए, क्रॉस-ऑरिजिन सबरिसॉर्स अनुरोधों में, रेफ़रर को ऑरिजिन के लिए हमेशा छोटा कर सकते हैं.
• Referer हेडर (और document.referrer) में आपकी ज़रूरत से ज़्यादा डेटा हो सकता है. उदाहरण के लिए, अगर आपको सिर्फ़ यह जानना है कि अनुरोध क्रॉस-ऑरिजिन है या नहीं, तो इसमें पूरा यूआरएल हो सकता है.

Referer के विकल्प

इन मामलों में आपको अन्य विकल्पों पर विचार करना पड़ सकता है:

• आपकी साइट की एक ज़रूरी सुविधा, क्रॉस-ऑरिजिन से मिलने वाले अनुरोधों के रेफ़रर यूआरएल का इस्तेमाल करती है.
• अब आपकी साइट को रेफ़रर यूआरएल का वह हिस्सा नहीं मिल रहा है जो क्रॉस-ऑरिजिन अनुरोध में ज़रूरी है. ऐसा तब होता है, जब अनुरोध करने वाला अपनी नीति में बदलाव करता है या जब उसने कोई नीति सेट नहीं की होती है और ब्राउज़र की डिफ़ॉल्ट नीति बदल जाती है (जैसे Chrome 85 में).

विकल्प तय करने के लिए, सबसे पहले यह विश्लेषण करें कि आप रेफ़रर के किस हिस्से का इस्तेमाल कर रहे हैं.

अगर आपको सिर्फ़ ऑरिजिन की ज़रूरत है

• अगर किसी ऐसी स्क्रिप्ट में रेफ़रर का इस्तेमाल किया जा रहा है जिसमें पेज का टॉप लेवल ऐक्सेस है, तो window.location.origin एक विकल्प है.
• अगर उपलब्ध हो, तो Origin और Sec-Fetch-Site जैसे हेडर आपको Origin देते हैं या बताते हैं कि अनुरोध क्रॉस-ऑरिजिन है या नहीं और यह वही हो सकता है जिसकी आपको ज़रूरत है.

अगर आपको यूआरएल के अन्य एलिमेंट (पाथ, क्वेरी पैरामीटर...) की ज़रूरत है, तो

• अनुरोध पैरामीटर आपके इस्तेमाल के उदाहरण का समाधान कर सकते हैं, जिससे आपको रेफ़रर को पार्स करने का काम नहीं करना पड़ता.
• अगर किसी ऐसी स्क्रिप्ट में रेफ़रर का इस्तेमाल किया जा रहा है जिसमें पेज का टॉप लेवल ऐक्सेस है, तो window.location.pathname एक विकल्प के तौर पर काम कर सकता है. यूआरएल का सिर्फ़ पाथ सेक्शन निकालें और उसे आर्ग्युमेंट के तौर पर पास करें, ताकि यूआरएल पैरामीटर में मौजूद कोई भी संवेदनशील जानकारी पास न हो.

अगर इन विकल्पों का इस्तेमाल नहीं किया जा सकता, तो:

• देखें कि क्या अपने सिस्टम में बदलाव करके, अनुरोध भेजने वाले व्यक्ति (उदाहरण के लिए, site-one.example) से वह जानकारी साफ़ तौर पर सेट की जा सकती है जो आपको किसी कॉन्फ़िगरेशन में ज़रूरी है.
  • Pro: site-one.example के उपयोगकर्ताओं के लिए, निजता की सुरक्षा को और बेहतर बनाएं, आने वाले समय के लिए ज़्यादा सुरक्षित.
  • नुकसान: संभावित रूप से आपकी ओर से या सिस्टम के उपयोगकर्ताओं के लिए ज़्यादा काम करना पड़ता है.
• देखें कि अनुरोध भेजने वाली साइट, हर एलिमेंट या हर अनुरोध के लिए no-referrer-when-downgrade की रेफ़रर-नीति सेट करने के लिए सहमत है या नहीं.
  • नुकसान: site-one.example उपयोगकर्ताओं के लिए, निजता की सुरक्षा कम हो सकती है. यह सभी ब्राउज़र पर काम नहीं करती.

क्रॉस-साइट अनुरोध जालसाज़ी (सीएसआरएफ़) से सुरक्षा

अनुरोध करने वाला व्यक्ति कभी भी, no-referrer नीति सेट करके, रेफ़रर को न भेजने का फ़ैसला ले सकता है. साथ ही, नुकसान पहुंचाने वाला कोई व्यक्ति, रेफ़रर की नकल भी कर सकता है.

अपनी मुख्य सुरक्षा के तौर पर सीएसआरएफ़ टोकन का इस्तेमाल करें. ज़्यादा सुरक्षा के लिए, SameSite का इस्तेमाल करें. साथ ही, Referer के बजाय, Origin (POST और सीओआरएस अनुरोधों पर उपलब्ध) और Sec-Fetch-Site जैसे हेडर का इस्तेमाल करें, अगर यह उपलब्ध है.

लॉग और डीबग करें

उपयोगकर्ताओं के निजी या संवेदनशील डेटा को सुरक्षित रखें, जो कि Referer में हो सकता है.

अगर सिर्फ़ ऑरिजिन का इस्तेमाल किया जा रहा है, तो देखें कि क्या Origin हेडर को विकल्प के तौर पर इस्तेमाल किया जा सकता है. इससे आपको वह जानकारी मिल सकती है जिसकी ज़रूरत आपको डीबग करने के मकसद से, आसान तरीके से और रेफ़रल देने वाले को पार्स किए बिना मिल सकती है.

पेमेंट्स

पेमेंट की सेवा देने वाली कंपनियां, सुरक्षा जांच के लिए आने वाले अनुरोधों के Referer हेडर पर भरोसा कर सकती हैं.

उदाहरण के लिए:

• उपयोगकर्ता online-shop.example/cart/checkout पर खरीदें बटन पर क्लिक करता है.
• ट्रांज़ैक्शन मैनेज करने के लिए, online-shop.example payment-provider.example को रीडायरेक्ट करता है.
• payment-provider.example इस अनुरोध के Referer की जांच, उन Referer वैल्यू की सूची से करता है जिन्हें व्यापारियों/कंपनियों/कारोबारियों ने सेट अप किया है. अगर यह सूची में दी गई किसी भी एंट्री से मेल नहीं खाती है, तो payment-provider.example उस अनुरोध को अस्वीकार कर देता है. अगर आईडी मेल खाता है, तो उपयोगकर्ता लेन-देन को आगे बढ़ा सकता है.

पेमेंट फ़्लो की सुरक्षा जांच के लिए सबसे सही तरीके

पेमेंट की सेवा देने वाली कंपनी के तौर पर, कुछ हमलों का पता लगाने के लिए Referer का इस्तेमाल, बेसिक जांच के तौर पर किया जा सकता है. हालांकि, Referer हेडर, जांच का भरोसेमंद आधार नहीं होता. अनुरोध करने वाली साइट, चाहे वह व्यापारी/कंपनी/कारोबारी मान्य हो या नहीं, वह no-referrer नीति सेट कर सकती है. इस नीति के तहत, पेमेंट की सेवा देने वाली कंपनी को Referer की जानकारी उपलब्ध नहीं कराई जाती.

Referer पर नज़र डालने से, पेमेंट की सेवा देने वाली कंपनियों को ऐसे हमलावरों का पता लगाने में मदद मिल सकती है जिन्होंने no-referrer की कोई नीति सेट नहीं की है. अगर Referer का इस्तेमाल पहली जांच के तौर पर किया जाता है, तो:

• ऐसी उम्मीद न करें कि Referer हमेशा मौजूद हो. अगर यह मौजूद है, तो सिर्फ़ उस कम से कम डेटा की जांच करें जिसमें यह डेटा शामिल हो सकता है, जो कि ऑरिजिन है.
  • अनुमति वाले Referer वैल्यू की सूची सेट करते समय, सिर्फ़ ऑरिजिन और कोई पाथ नहीं शामिल करें.
  • उदाहरण के लिए, online-shop.example के लिए Referer की वैल्यू online-shop.example होनी चाहिए, न कि online-shop.example/cart/checkout. इस तरह की Referer वैल्यू या Referer वैल्यू नहीं होगी या सिर्फ़ अनुरोध करने वाली साइट की ऑरिजिन, इस तरह की गड़बड़ी से बचा जा सकता है. इससे कारोबारी या कंपनी की Referrer-Policy के बारे में गलत अनुमान नहीं लगाया जा सकता.
• अगर Referer मौजूद नहीं है या मौजूद है और Referer के ऑरिजिन की जांच हो गई है, तो पुष्टि करने का कोई दूसरा और ज़्यादा भरोसेमंद तरीका इस्तेमाल किया जा सकता है.

पेमेंट की पुष्टि ज़्यादा सटीक तरीके से करने के लिए, अनुरोध करने वाले को एक यूनीक कुंजी के साथ अनुरोध के पैरामीटर हैश करने दें. इसके बाद, पेमेंट की सेवा देने वाली कंपनी उस हैश का कैलकुलेशन कर सकती है जो आपके हिसाब से मेल खाता हो.

जब एचटीटीपी व्यापारी या कंपनी की बिना रेफ़रर नीति वाली साइट, एचटीटीपीएस पेमेंट की सेवा देने वाली कंपनी को रीडायरेक्ट करती है, तब Referer का क्या होगा?

एचटीटीपीएस से पेमेंट की सेवा देने वाली कंपनी को अनुरोध करने में, कोई Referer नहीं दिखता. इसकी वजह यह है कि अगर किसी वेबसाइट पर कोई नीति सेट नहीं है, तो ज़्यादातर ब्राउज़र डिफ़ॉल्ट रूप से strict-origin-when-cross-origin या no-referrer-when-downgrade का इस्तेमाल करते हैं. Chrome की नई डिफ़ॉल्ट नीति में बदलाव से इस व्यवहार में कोई बदलाव नहीं होगा.

ध्यान दें: अगर आपकी वेबसाइट, एचटीटीपी का इस्तेमाल करती है, तो एचटीटीपीएस पर माइग्रेट करें.

नतीजा

सुरक्षा के लिए रेफ़र करने वाली रेफ़रल नीति बनाना, अपने उपयोगकर्ताओं की निजता को बेहतर करने का एक बेहतरीन तरीका है.

अपने उपयोगकर्ताओं को सुरक्षित रखने से जुड़ी अलग-अलग तकनीकों के बारे में ज़्यादा जानने के लिए, हमारा सुरक्षित और सुरक्षित कलेक्शन देखें

रिसॉर्स

• "same-site" और "same-origin" को समझना
• एक नया सुरक्षा हेडर: रेफ़रर नीति (2017)
• एमडीएन पर रेफ़रर-नीति
• रेफ़रर हेडर: एमडीएन पर निजता और सुरक्षा से जुड़ी समस्याएं
• Chrome में बदलाव: ब्लिंक इंटेंट, जिसे लागू करना है
• Chrome में बदलाव: ब्लिंक इंटेंट भेजने का मतलब है
• Chrome में बदलाव: स्टेटस एंट्री
• Chrome में बदलाव: 85 बीटा ब्लॉग पोस्ट
• रेफ़रर ट्रिमिंग GitHub थ्रेड: अलग-अलग ब्राउज़र क्या करते हैं
• रेफ़रर-नीति की खास जानकारी

सभी समीक्षकों को योगदान और सुझाव देने के लिए धन्यवाद. खास तौर पर, डेविड वैन क्लेव, माइक वेस्ट, सैम डटन, रोवन मेरीवुड, जेक्स, और केस बास्क.