हर कुकी में एक की-वैल्यू पेयर के साथ-साथ कई एट्रिब्यूट होते हैं. ये एट्रिब्यूट यह कंट्रोल करते हैं कि कुकी का इस्तेमाल कब और कहां किया जाए.
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 की कुकी की हीरो इमेज