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

Rowan Merewood

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

RFC6265bis यहां 'साइट' का मतलब समझना ज़रूरी है. साइट, डोमेन सफ़िक्स और डोमेन के उस हिस्से का कॉम्बिनेशन होती है जो डोमेन सफ़िक्स से ठीक पहले आता है. उदाहरण के लिए, www.web.dev डोमेन, web.dev साइट का हिस्सा है.

मुख्य शब्द: अगर उपयोगकर्ता www.web.dev पर है और static.web.dev से किसी इमेज का अनुरोध करता है, तो यह same-site अनुरोध है.

पब्लिक सफ़िक्स लिस्ट से यह तय होता है कि किन पेजों को एक ही साइट पर माना जाए. यह सिर्फ़ .com जैसे टॉप-लेवल डोमेन पर निर्भर नहीं करता, बल्कि इसमें github.io जैसी सेवाएं भी शामिल हो सकती हैं. इससे your-project.github.io और my-project.github.io को अलग-अलग साइट माना जा सकता है.

मुख्य शब्द: अगर उपयोगकर्ता your-project.github.io पर है और my-project.github.io से किसी इमेज का अनुरोध करता है, तो यह cross-site अनुरोध है.

कुकी के इस्तेमाल के बारे में बताने के लिए, SameSite एट्रिब्यूट का इस्तेमाल करना

कुकी पर मौजूद SameSite एट्रिब्यूट, इस व्यवहार को कंट्रोल करने के तीन अलग-अलग तरीके उपलब्ध कराता है. आपके पास एट्रिब्यूट तय न करने का विकल्प होता है. इसके अलावा, Strict या Lax का इस्तेमाल करके, कुकी को same-site अनुरोधों तक सीमित किया जा सकता है.

अगर 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 के प्रस्ताव, Incrementally Better Cookies में दो मुख्य बदलाव किए गए हैं:

• SameSite एट्रिब्यूट के बिना कुकी को SameSite=Lax माना जाता है.
• SameSite=None वाली कुकी के लिए, Secure भी तय करना ज़रूरी है. इसका मतलब है कि इसके लिए सुरक्षित कॉन्टेक्स्ट की ज़रूरत होती है.

ये दोनों बदलाव, उन ब्राउज़र के साथ काम करते हैं जिन्होंने SameSite एट्रिब्यूट के पिछले वर्शन को सही तरीके से लागू किया है. साथ ही, उन ब्राउज़र के साथ भी काम करते हैं जो SameSite के पुराने वर्शन के साथ काम नहीं करते. इनका मकसद, कुकी के व्यवहार और उसके इस्तेमाल के बारे में साफ़ तौर पर बताकर, ब्राउज़र के डिफ़ॉल्ट व्यवहार पर डेवलपर की निर्भरता को कम करना है. ऐसे क्लाइंट को SameSite=None को अनदेखा करना चाहिए जो इसे नहीं पहचानते.

डिफ़ॉल्ट रूप से SameSite=Lax

अगर SameSite एट्रिब्यूट तय किए बिना कोई कुकी भेजी जाती है, तो ब्राउज़र उस कुकी को SameSite=Lax पर सेट की गई कुकी की तरह मानता है. हमारा सुझाव है कि SameSite=Lax को साफ़ तौर पर सेट करें, ताकि सभी ब्राउज़र पर उपयोगकर्ताओं को एक जैसा अनुभव मिले.

SameSite=None के लिए सुरक्षित होना ज़रूरी है

SameSite=None का इस्तेमाल करके, cross-site कुकी बनाते समय, आपको उन्हें Secure पर भी सेट करना होगा, ताकि ब्राउज़र उन्हें स्वीकार कर सके:

Set-Cookie: widget_session=abc123; SameSite=None; Secure

Chrome 76 से, इस व्यवहार को आज़माया जा सकता है. इसके लिए, about://flags/#cookies-without-same-site-must-be-secure को चालू करें. इसके अलावा, Firefox 69 से, network.cookie.sameSite.noneRequiresSecure को about:config में सेट करके भी इस व्यवहार को आज़माया जा सकता है.

हमारा सुझाव है कि मौजूदा कुकी को जल्द से जल्द Secure पर अपडेट करें. अगर आप ऐसी सेवाओं पर निर्भर हैं जो आपकी साइट पर तीसरे पक्ष का कॉन्टेंट उपलब्ध कराती हैं, तो पक्का करें कि आपका सेवा देने वाला, अपनी कुकी को अपडेट करे. साथ ही, अपनी साइट पर मौजूद स्निपेट या डिपेंडेंसी को अपडेट करें, ताकि यह पक्का किया जा सके कि वह नए व्यवहार का इस्तेमाल करती है.

SameSite कुकी के इस्तेमाल के उदाहरण

में किए गए इन बदलावों को सही तरीके से मैनेज करने के लिए, अपनी कुकी को अपडेट करने और ब्राउज़र के व्यवहार में अंतर के बारे में ज़्यादा जानने के लिए, SameSite कुकी के इस्तेमाल के उदाहरण लेख पढ़ें.SameSite=None

Lily Chen, Malte Ubl, Mike West, Rob Dodson, Tom Steiner, और Vivek Sekhar के योगदान और सुझावों के लिए धन्यवाद.

कुकी की हीरो इमेज, Unsplash पर Pille-Riin Priske ने ली है