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

Maud Nalpas

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

खास जानकारी

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

ध्यान दें:

• अगर आपको "साइट" और "ऑरिजिन" के बीच के अंतर के बारे में नहीं पता है, तो "एक ही साइट" और "एक ही ऑरिजिन" के बारे में जानकारी देखें.
• ओरिजनल स्पेसिफ़िकेशन में वर्तनी की गड़बड़ी की वजह से, Referer हेडर में R मौजूद नहीं है. JavaScript और डीओएम में Referrer-Policy हेडर और referrer की स्पेलिंग सही है.

रेफ़र करने वाले और रेफ़र करने वाले से जुड़ी नीति के बारे में बुनियादी जानकारी

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

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

रेफ़रर हेडर वाला एचटीटीपी अनुरोध.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• स्कीम (एचटीटीपी बनाम एचटीटीपीएस) को ध्यान में रखने वाली सभी नीतियां (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" />

या सर्वर साइड, जैसे कि Express में:

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) को किसी कॉन्फ़िगरेशन में, आपकी ज़रूरत की जानकारी साफ़ तौर पर सेट करने के लिए कहा जा सकता है.
  • फ़ायदे: 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 के बारे में अनुमान लगाने से होने वाली गड़बड़ियों से बचा जा सकता है.
• अगर Referer मौजूद नहीं है या वह मौजूद है और आपके Referer के ऑरिजिन की जांच हो जाती है, तो पुष्टि करने के किसी दूसरे तरीके का इस्तेमाल किया जा सकता है. यह तरीका ज़्यादा भरोसेमंद होगा.

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

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

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

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

नतीजा

सुरक्षित रेफ़रर नीति, लोगों की निजता बनाए रखने का एक शानदार तरीका है.

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

संसाधन

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

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