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

Maud Nalpas

इस पेज पर, रेफ़रर-नीति सेट करने और रेफ़र करने वाले यूआरएल का इस्तेमाल करें.

खास जानकारी

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

रेफ़रर और रेफ़रल देने वाले से जुड़ी नीति 101

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 (पीओएसटी और सीओआरएस के अनुरोधों पर उपलब्ध है) और 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 का बदलाव से इस व्यवहार में कोई बदलाव नहीं होगा.

नतीजा

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

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

संसाधन

• "एक ही साइट" को समझना और "सेम-ऑरिजिन"
• सुरक्षा से जुड़ा नया हेडर: रेफ़रर नीति (2017)
• रेफ़रलकर्ता-नीति चालू एमडीएन
• रेफ़रर हेडर: निजता और सुरक्षा से जुड़ी समस्याएं एमडीएन
• Chrome में बदलाव: इसका इंटेंट ब्लिंक करें लागू करें
• Chrome में बदलाव: इसका इंटेंट ब्लिंक करें जहाज़
• Chrome में बदलाव: स्टेटस एंट्री
• Chrome बदलाव: 85 बीटा blogpost
• GitHub थ्रेड में काट-छांट करने वाला रेफ़रर: कौनसे अलग-अलग ब्राउज़र ऐसा करें
• रेफ़रल देने वाले से जुड़ी नीति की खास जानकारी

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