इस पेज पर, रेफ़रल देने वाले से जुड़ी नीति सेट करने और आने वाले अनुरोधों में रेफ़रर का इस्तेमाल करने के सबसे सही तरीके बताए गए हैं.
खास जानकारी
- क्रॉस-ऑरिजिन की जानकारी लीक होने से, वेब इस्तेमाल करने वालों की निजता को नुकसान पहुंचता है. सुरक्षा के लिए, रेफ़रर की नीति से आपको मदद मिल सकती है.
strict-origin-when-cross-origin
की रेफ़रर नीति सेट करें. यह, रेफ़रर की ज़्यादातर उपयोगिता को सुरक्षित रखता है. साथ ही, इससे डेटा के क्रॉस-ऑरिजिन के लीक होने के जोखिम को भी कम किया जाता है.- क्रॉस-साइट अनुरोध जालसाज़ी (सीएसआरएफ़) से सुरक्षा के लिए, रेफ़रर का इस्तेमाल न करें. इसके बजाय, सीएसआरएफ़ टोकन और अन्य हेडर का इस्तेमाल सुरक्षा को और बेहतर बनाने के लिए करें.
रेफ़रर और रेफ़रर-नीति 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 के जैसा ही होता है, लेकिन इसमें कुछ खास अंतर होते हैं. ज़्यादा जानकारी के लिए,
प्रिवेंशन ट्रैकिंग को रोकना देखें.
|
रेफ़रर नीति सेट करने के सबसे सही तरीके
आपकी साइट पर रेफ़रल देने वाली नीतियां सेट करने के कई तरीके हैं:
- एचटीटीपी हेडर के तौर पर
- एचटीएमएल में
- हर अनुरोध के आधार पर JavaScript से
अलग-अलग पेजों, अनुरोधों या एलिमेंट के लिए, अलग-अलग नीतियां सेट की जा सकती हैं.
एचटीटीपी हेडर और मेटा एलिमेंट, दोनों ही पेज लेवल होते हैं. किसी एलिमेंट की असरदार नीति तय करने का प्राथमिकता क्रम इस तरह है:
- एलिमेंट के लेवल पर नीति
- पेज स्तर नीति
- ब्राउज़र की डिफ़ॉल्ट सेटिंग
उदाहरण:
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
) से वह जानकारी साफ़ तौर पर सेट की जा सकती है जो आपको किसी कॉन्फ़िगरेशन में ज़रूरी है.- Pro:
site-one.example
के उपयोगकर्ताओं के लिए, निजता की सुरक्षा को और बेहतर बनाएं, आने वाले समय के लिए ज़्यादा सुरक्षित. - नुकसान: संभावित रूप से आपकी ओर से या सिस्टम के उपयोगकर्ताओं के लिए ज़्यादा काम करना पड़ता है.
- Pro:
- देखें कि अनुरोध भेजने वाली साइट, हर एलिमेंट या हर अनुरोध के लिए
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 थ्रेड: अलग-अलग ब्राउज़र क्या करते हैं
- रेफ़रर-नीति की खास जानकारी
सभी समीक्षकों को योगदान और सुझाव देने के लिए धन्यवाद. खास तौर पर, डेविड वैन क्लेव, माइक वेस्ट, सैम डटन, रोवन मेरीवुड, जेक्स, और केस बास्क.