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

Maud Nalpas

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

खास जानकारी

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

रेफ़रर और रेफ़रर-पॉलिसी के बारे में बुनियादी जानकारी

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

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

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

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

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

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

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

छठा यूआरएल, क्षमता वाला यूआरएल है. अगर यह ईमेल किसी ऐसे व्यक्ति को मिलता है जिसे यह नहीं मिलना चाहिए, तो कोई दुर्भावनापूर्ण व्यक्ति इस उपयोगकर्ता के खाते का ऐक्सेस पा सकता है.

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

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

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

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

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

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

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

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

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

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

अक्टूबर 2021 तक

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

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

अपनी साइट के लिए रेफ़रर नीतियां सेट करने के अलग-अलग तरीके हैं:

• एचटीटीपी हेडर के तौर पर
• अपने एचटीएमएल में
• 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 दिखता है.

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

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

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

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

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

नतीजा

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

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

संसाधन

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

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