हर कुकी में कई एट्रिब्यूट के साथ-साथ एक की-वैल्यू पेयर होता है. इससे यह कंट्रोल किया जाता है कि कुकी को कब और कहां इस्तेमाल करना है.
SameSite
एट्रिब्यूट के बारे में जानकारी (RFC6265bis में दी गई) की मदद से, आपको यह बताने की सुविधा मिलती है कि आपकी कुकी, पहले पक्ष (ग्राहक) या एक ही साइट के कॉन्टेक्स्ट तक ही सीमित है. यहां 'साइट' का मतलब समझने में मदद मिलती है.
यह साइट, डोमेन सफ़िक्स और इसके ठीक पहले वाले डोमेन के हिस्से का कॉम्बिनेशन है. उदाहरण के लिए, www.web.dev
डोमेन, web.dev
साइट का हिस्सा है.
मुख्य शब्द: अगर उपयोगकर्ता www.web.dev
का इस्तेमाल करता है और static.web.dev
से इमेज का अनुरोध करता है, तो यह उसी साइट के लिए होगा.
सार्वजनिक सफ़िक्स सूची से पता चलता है कि एक ही साइट पर कौनसे पेज
हैं. यह सिर्फ़ .com
जैसे टॉप लेवल डोमेन पर निर्भर नहीं करता,
बल्कि इसमें github.io
जैसी सेवाएं भी शामिल हो सकती हैं. इससे your-project.github.io
और my-project.github.io
को अलग-अलग साइटों के तौर पर गिना जाता है.
मुख्य शब्द: अगर उपयोगकर्ता your-project.github.io
का इस्तेमाल करता है और my-project.github.io
से ऐसी इमेज का अनुरोध करता है जो क्रॉस-साइट से किया गया है.
कुकी के इस्तेमाल का एलान करने के लिए, SameSite
एट्रिब्यूट का इस्तेमाल करें
कुकी पर मौजूद SameSite
एट्रिब्यूट, इस व्यवहार को कंट्रोल करने के तीन अलग-अलग तरीके देता है. एट्रिब्यूट की वैल्यू न देने का विकल्प चुना जा सकता है. इसके अलावा, कुकी को एक ही साइट के अनुरोधों के लिए सीमित करने के लिए, Strict
या Lax
का इस्तेमाल किया जा सकता है.
SameSite
को Strict
पर सेट करने पर, आपकी कुकी सिर्फ़ पहले-पक्ष के हिसाब से भेजी जा सकती है. इसका मतलब है कि कुकी की साइट, ब्राउज़र के पता बार में दिखाई गई साइट से मेल खाती है. इसलिए, अगर promo_shown
कुकी इस तरह सेट की गई है:
Set-Cookie: promo_shown=1; SameSite=Strict
जब उपयोगकर्ता आपकी साइट पर होता है, तो कुकी को उम्मीद के मुताबिक अनुरोध के साथ भेजा जाता है.
हालांकि, अगर उपयोगकर्ता आपकी साइट पर किसी दूसरे लिंक से जाता है, तो उस शुरुआती अनुरोध पर कुकी नहीं भेजी जाती.
यह उन सुविधाओं से जुड़ी कुकी के लिए अच्छा है जो हमेशा एक शुरुआती नेविगेशन से जुड़ी होती हैं, जैसे कि पासवर्ड बदलना या खरीदारी करना. हालांकि, यह promo_shown
जैसी कुकी के लिए बहुत सीमित है. अगर आपका पाठक, साइट पर दिए गए लिंक को फ़ॉलो करता है, तो वह चाहता है कि कुकी भेजी जाए, ताकि उसकी प्राथमिकता लागू की जा सके.
SameSite=Lax
, ब्राउज़र को इन टॉप-लेवल नेविगेशन के साथ कुकी भेजने की अनुमति देता है. उदाहरण के लिए, अगर कोई दूसरी साइट आपकी साइट के कॉन्टेंट का रेफ़रंस देती है, तो बिल्ली की फ़ोटो इस्तेमाल करें और अपने लेख का लिंक इस तरह दें:
<p>Look at this amazing cat!</p>
<img src="https://blog.example/blog/img/amazing-cat.png" />
<p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>
कुकी को Lax
पर इस तरह सेट करें:
Set-Cookie: promo_shown=1; SameSite=Lax
जब ब्राउज़र दूसरे व्यक्ति के ब्लॉग के लिए amazing-cat.png
का अनुरोध करता है, तो आपकी साइट कुकी नहीं भेजती है. हालांकि, जब लोग आपकी साइट पर cat.html
के लिंक को फ़ॉलो करते हैं, तो उस अनुरोध में कुकी शामिल होती है.
हमारा सुझाव है कि इस तरह SameSite
का इस्तेमाल करें. साथ ही, वेबसाइट
डिसप्ले पर असर डालने वाली कुकी को Lax
पर और उपयोगकर्ता की कार्रवाइयों से जुड़ी कुकी को Strict
पर सेट करें.
SameSite
को None
पर सेट करके भी यह बताया जा सकता है कि आपको कुकी को हर समय भेजना है. अगर कोई ऐसी सेवा दी जाती है जिसका इस्तेमाल दूसरी साइटें करती हैं, जैसे कि विजेट, एम्बेड किया गया कॉन्टेंट, अफ़िलिएट प्रोग्राम, विज्ञापन दिखाना या एक से ज़्यादा साइटों पर साइन-इन करना, तो None
का इस्तेमाल करके पक्का करें कि आपका इंटेंट साफ़ है.
SameSite फ़ाइल के बिना, डिफ़ॉल्ट व्यवहार में बदलाव किया गया
ब्राउज़र सहायता
- 80
- 86
- x
SameSite
एट्रिब्यूट का इस्तेमाल कई जगहों पर किया जा सकता है. हालांकि, इसे ज़्यादातर लोगों ने इस्तेमाल नहीं किया है.
पहले, SameSite
के बिना कुकी सेट करने से वे डिफ़ॉल्ट रूप से हर समय पर भेजी जाती थीं. इससे उपयोगकर्ता, सीएसआरएफ़ और अनजाने में जानकारी लीक होने का खतरा बना रहते थे. डेवलपर को अपने मकसद के बारे में बताने और
उपयोगकर्ताओं को सुरक्षित अनुभव देने के लिए बढ़ावा देने के लिए, आईईटीएफ़ के प्रस्ताव में
इंक्रीमेंटल तौर पर बेहतर कुकी
दो अहम बदलावों के बारे में बताया गया है:
- बिना
SameSite
एट्रिब्यूट वाली कुकी कोSameSite=Lax
माना जाता है. SameSite=None
वाली कुकी मेंSecure
भी होना ज़रूरी है. इसका मतलब है कि उन्हें सुरक्षित कॉन्टेक्स्ट की ज़रूरत होती है.
ये दोनों बदलाव उन ब्राउज़र पर भी लागू होते हैं जिन्होंने SameSite
एट्रिब्यूट के पिछले वर्शन को सही तरीके से लागू किया है. साथ ही, ये ऐसे ब्राउज़र पर भी काम करते हैं जो SameSite
के पुराने वर्शन पर काम नहीं करते. इनका मकसद, कुकी के काम करने का तरीका और उसके सही इस्तेमाल को अश्लील बनाकर, ब्राउज़र के डिफ़ॉल्ट व्यवहार पर डेवलपर का भरोसा कम करना है. जो क्लाइंट SameSite=None
को नहीं पहचान सकता उसे इसे अनदेखा करना चाहिए.
डिफ़ॉल्ट रूप से SameSite=Lax
अगर किसी कुकी को उसके SameSite
एट्रिब्यूट की जानकारी दिए बिना भेजा जाता है, तो ब्राउज़र उस कुकी को ऐसे ही मानता है कि उसे SameSite=Lax
पर सेट किया गया है. हमारा सुझाव है कि आप SameSite=Lax
को साफ़ तौर पर सेट करें, ताकि सभी ब्राउज़र पर उपयोगकर्ताओं को एक जैसा अनुभव मिल सके.
SameSite=None
सुरक्षित होना चाहिए
जब SameSite=None
का इस्तेमाल करके क्रॉस-साइट कुकी बनाई जाती हैं, तो आपको उन्हें Secure
पर भी सेट करना होगा, ताकि ब्राउज़र उन्हें स्वीकार कर सके:
Set-Cookie: widget_session=abc123; SameSite=None; Secure
about://flags/#cookies-without-same-site-must-be-secure
को चालू करके, Chrome 76 और Firefox 69 में इस व्यवहार की जांच की जा सकती है. इसके लिए, about:config
में network.cookie.sameSite.noneRequiresSecure
को सेट करें.
हमारा सुझाव है कि आप मौजूदा कुकी को जल्द से जल्द Secure
में अपडेट करें.
अगर आप अपनी साइट पर तीसरे पक्ष का कॉन्टेंट उपलब्ध कराने वाली सेवाओं का इस्तेमाल करते हैं, तो पक्का करें कि
सेवा देने वाली कंपनी अपनी कुकी अपडेट करे. साथ ही, अपनी साइट पर मौजूद सभी स्निपेट या निर्भरता को अपडेट करें, ताकि यह पक्का किया जा सके कि
वे नए व्यवहार का इस्तेमाल कर रहे हैं.
कुकी की SameSite
रेसिपी
SameSite=None
में इन बदलावों को ठीक से मैनेज करने के लिए, अपनी कुकी को अपडेट करने और ब्राउज़र के काम करने के तरीके में अंतर के बारे में ज़्यादा जानकारी के लिए, SameSite कुकी बनाने की रेसिपी फ़ॉलो अप-लेख पढ़ें.
लिली चेन, माल्टे उबील, माइक वेस्ट, रॉब डॉडसन, टॉम स्टेनर, और विवेक शेखर के योगदान और सुझाव, शिकायत या राय के लिए धन्यवाद.
कुकी हीरो इमेज Pill-Riin Priske पर Unsplash