SameSite कुकी के बारे में बताया गया

Rowan Merewood

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

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 की कुकी की हीरो इमेज