हर कुकी में एक की-वैल्यू पेयर के साथ-साथ कई एट्रिब्यूट होते हैं. ये एट्रिब्यूट यह कंट्रोल करते हैं कि कुकी का इस्तेमाल कब और कहां किया जाए.
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 के बिना डिफ़ॉल्ट व्यवहार में बदलाव
ब्राउज़र के इस्तेमाल से जुड़ी सहायता
SameSite
एट्रिब्यूट का इस्तेमाल कई प्लैटफ़ॉर्म पर किया जा सकता है. हालांकि, इसे कई प्लैटफ़ॉर्म पर इस्तेमाल नहीं किया जाता.
पहले, SameSite
के बिना कुकी सेट करने पर, वे डिफ़ॉल्ट रूप से सभी कॉन्टेक्स्ट में भेजी जाती थीं. इससे उपयोगकर्ता, सीएसआरएफ़ और अनजाने में जानकारी लीक होने के खतरे में पड़ जाते थे. डेवलपर को अपने इंटेंट के बारे में बताने और उपयोगकर्ताओं को सुरक्षित अनुभव देने के लिए, IETF के प्रस्ताव, बेहतर कुकी में दो मुख्य बदलाव किए गए हैं:
- जिन कुकी में
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
Chrome 76 में इस सुविधा को आज़माने के लिए, about://flags/#cookies-without-same-site-must-be-secure
को चालू करें. Firefox 69 में, about:config
में network.cookie.sameSite.noneRequiresSecure
को सेट करके भी इस सुविधा को आज़माया जा सकता है.
हमारा सुझाव है कि आप मौजूदा कुकी को जल्द से जल्द Secure
पर अपडेट करें.
अगर आपकी साइट पर तीसरे पक्ष का कॉन्टेंट उपलब्ध कराने वाली सेवाओं का इस्तेमाल किया जाता है, तो पक्का करें कि सेवा देने वाली कंपनी अपनी कुकी अपडेट कर रही हो. साथ ही, अपनी साइट पर मौजूद किसी भी स्निपेट या डिपेंडेंसी को अपडेट करें, ताकि यह पक्का किया जा सके कि वह नए व्यवहार का इस्तेमाल करती है.
SameSite
कुकी की रेसिपी
SameSite=None
में किए गए इन बदलावों और ब्राउज़र के व्यवहार में हुए अंतर को मैनेज करने के लिए, अपनी कुकी अपडेट करने के बारे में ज़्यादा जानने के लिए, SameSite कुकी रेसिपी लेख पढ़ें.
Lily Chen, Malte Ubl, Mike West, Rob Dodson, Tom Steiner, और Vivek Sekhar के योगदान और सुझावों के लिए धन्यवाद.
Unsplash पर, Pille-Riin Priske की कुकी की हीरो इमेज