SameSite कुकी रेसिपी

Chrome, Firefox, Edge, वगैरह, IETF के प्रस्ताव, Incrementally Better Cookies के मुताबिक अपने डिफ़ॉल्ट व्यवहार में बदलाव कर रहे हैं, ताकि:

  • SameSite एट्रिब्यूट के बिना कुकी को SameSite=Lax के तौर पर माना जाए. इसका मतलब है कि डिफ़ॉल्ट व्यवहार के तहत, कुकी को पहले पक्ष के कॉन्टेक्स्ट तक सिर्फ़ सीमित रखा जाए.
  • अलग-अलग साइटों पर इस्तेमाल की जाने वाली कुकी के लिए, तीसरे पक्ष के कॉन्टेक्स्ट में शामिल करने के लिए, SameSite=None; Secure बताना ज़रूरी है.

अगर आपने अब तक ऐसा नहीं किया है, तो आपको तीसरे पक्ष की कुकी के एट्रिब्यूट अपडेट करने चाहिए, ताकि उन्हें आने वाले समय में ब्लॉक न किया जाए.

Browser Support

  • Chrome: 51.
  • Edge: 16.
  • Firefox: 60.
  • Safari: 13.

अलग-अलग साइटों या तीसरे पक्ष की कुकी के इस्तेमाल के उदाहरण

इस्तेमाल के कई सामान्य उदाहरण और पैटर्न हैं, जिनमें तीसरे पक्ष के कॉन्टेक्स्ट में कुकी भेजनी पड़ती हैं. अगर आप इनमें से किसी एक उदाहरण के मुताबिक सेवा देते हैं या इस पर निर्भर हैं, तो पक्का करें कि आप या सेवा देने वाला, अपनी कुकी को अपडेट कर रहा हो, ताकि सेवा सही तरीके से काम करती रहे.

<iframe> में मौजूद कॉन्टेंट

किसी दूसरी साइट का कॉन्टेंट, जो <iframe> में दिखाई देता है, तीसरे पक्ष के कॉन्टेक्स्ट में होता है. इस्तेमाल के सामान्य उदाहरणों में ये शामिल हैं:

  • एम्बेड किया गया कॉन्टेंट, जिसे वीडियो, मैप, कोड के सैंपल, और सोशल पोस्ट जैसी अन्य साइटों से शेयर किया गया है.
  • पेमेंट, कैलेंडर, बुकिंग, और रिज़र्वेशन की सुविधाओं जैसी बाहरी सेवाओं के विजेट.
  • सोशल बटन या धोखाधड़ी से बचाव सेवाओं जैसे विजेट, जो कम दिखने वाले <iframes> बनाते हैं.

यहां कुकी का इस्तेमाल, सेशन की स्थिति बनाए रखने, सामान्य प्राथमिकताएं सेव करने, आंकड़े दिखाने या मौजूदा खातों वाले उपयोगकर्ताओं के लिए कॉन्टेंट को उनकी दिलचस्पी के हिसाब से बनाने के लिए किया जा सकता है.

ब्राउज़र विंडो का डायग्राम. इसमें एम्बेड किए गए कॉन्टेंट का यूआरएल, पेज के यूआरएल से मेल नहीं खाता.
अगर एम्बेड किया गया कॉन्टेंट, टॉप-लेवल ब्राउज़िंग कॉन्टेक्स्ट वाली साइट से नहीं आता है, तो यह तीसरे पक्ष का कॉन्टेंट होता है.

वेब, स्वाभाविक तौर पर कंपोज़ किया जा सकने वाला होने की वजह से, <iframes> का इस्तेमाल, टॉप-लेवल या पहले पक्ष के कॉन्टेक्स्ट में देखे गए कॉन्टेंट को एम्बेड करने के लिए भी किया जाता है. आईफ़्रेम में दिखाई देने वाली साइट की ओर से इस्तेमाल की जाने वाली सभी कुकी, तीसरे पक्ष की कुकी मानी जाती हैं. अगर साइटें बनाई जा रही हैं और उन्हें दूसरी साइटों पर एम्बेड करना है. साथ ही, उन्हें काम करने के लिए कुकी की ज़रूरत है, तो यह भी पक्का करना होगा कि उन्हें अलग-अलग साइटों पर इस्तेमाल करने के लिए मार्क किया गया हो. इसके अलावा, यह भी पक्का करना होगा कि कुकी के बिना भी साइटें सही तरीके से काम करें.

अलग-अलग साइटों पर किए जाने वाले "असुरक्षित" अनुरोध

यहां "असुरक्षित" शब्द सुनकर चिंता हो सकती है, लेकिन इसका मतलब है कि ऐसा कोई भी अनुरोध जिससे स्थिति में बदलाव हो सकता है. वेब पर, यह मुख्य रूप से POST अनुरोध होते हैं. SameSite=Lax के तौर पर मार्क की गई कुकी, सुरक्षित टॉप-लेवल नेविगेशन पर भेजी जाती हैं. जैसे, किसी दूसरी साइट पर जाने के लिए किसी लिंक पर क्लिक करना. हालांकि, POST का इस्तेमाल करके किसी दूसरी साइट पर <form> सबमिट करने पर, कुकी शामिल नहीं होती हैं.

एक पेज से दूसरे पेज पर जाने वाले अनुरोध का डायग्राम.
अगर आने वाले अनुरोध में "सुरक्षित" तरीके का इस्तेमाल किया जाता है, तो पेज कुकी भेजता है.

इस पैटर्न का इस्तेमाल उन साइटों के लिए किया जाता है जो उपयोगकर्ता को किसी रिमोट सेवा पर रीडायरेक्ट कर सकती हैं, ताकि वापस आने से पहले कोई कार्रवाई की जा सके. उदाहरण के लिए, तीसरे पक्ष के आइडेंटिटी प्रोवाइडर पर रीडायरेक्ट करना. उपयोगकर्ता के साइट छोड़ने से पहले, एक कुकी सेट की जाती है. इसमें एक बार इस्तेमाल किया जा सकने वाला टोकन होता है. ऐसा माना जाता है कि इस टोकन की जांच, वापस आने वाले अनुरोध पर की जा सकती है, ताकि दूसरी साइट से किए गए फ़र्ज़ी अनुरोध (सीएसआरएफ़) वाले हमलों को कम किया जा सके. अगर वापस आने वाला अनुरोध POST के ज़रिए आता है, तो आपको कुकी को SameSite=None; Secure के तौर पर मार्क करना होगा.

रिमोट रिसॉर्स

किसी पेज पर मौजूद कोई भी रिमोट रिसॉर्स, जैसे कि <img> टैग या <script> टैग से, अनुरोध के साथ कुकी भेजे जाने पर निर्भर हो सकता है. इस्तेमाल के सामान्य उदाहरणों में, ट्रैकिंग पिक्सल और कॉन्टेंट को उपयोगकर्ता की दिलचस्पी के हिसाब से बनाना शामिल है.

यह आपके JavaScript से fetch या XMLHttpRequest का इस्तेमाल करके भेजे गए अनुरोधों पर भी लागू होता है. अगर fetch() को credentials: 'include' विकल्प के साथ कॉल किया जाता है, तो इन अनुरोधों में कुकी शामिल होने की संभावना होती है. XMLHttpRequest के लिए, आम तौर पर withCredentials वैल्यू fo true से, कुकी के बारे में पता चलता है. अलग-अलग साइटों पर किए जाने वाले अनुरोधों में शामिल करने के लिए, इन कुकी को सही तरीके से मार्क करना ज़रूरी है.

WebView में मौजूद कॉन्टेंट

प्लेटफ़ॉर्म के हिसाब से बनाए गए किसी ऐप्लिकेशन में मौजूद WebView, ब्राउज़र की मदद से काम करता है. डेवलपर को यह जांच करनी होगी कि उनके ऐप्लिकेशन को प्रभावित करने वाली पाबंदियां या समस्याएं, उनके ऐप्लिकेशन के WebViews पर भी लागू होती हैं या नहीं.

Android, अपने प्लैटफ़ॉर्म के हिसाब से बनाए गए ऐप्लिकेशन को CookieManager API का इस्तेमाल करके, सीधे कुकी सेट करने की अनुमति भी देता है. हेडर या JavaScript का इस्तेमाल करके सेट की गई कुकी की तरह, अगर उन्हें अलग-अलग साइटों पर इस्तेमाल करना है, तो SameSite=None; Secure शामिल करें.

आज SameSite को लागू करने का तरीका

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

Set-Cookie: first_party_var=value; SameSite=Lax

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

Set-Cookie: third_party_var=value; SameSite=None; Secure

साथ काम नहीं करने वाले क्लाइंट को मैनेज करना

None को शामिल करने और डिफ़ॉल्ट व्यवहार को अपडेट करने के लिए किए गए ये बदलाव अब भी नए हैं. इसलिए, अलग-अलग ब्राउज़र इन्हें अलग-अलग तरीके से मैनेज करते हैं. जानकारियों के लिए, chromium.org पर अपडेट वाला पेज देखें. हालांकि, इस सूची में सभी ज्ञात समस्याएं शामिल नहीं हो सकती हैं.

एक संभावित तरीका यह है कि हर कुकी को नई और पुरानी, दोनों तरह की स्टाइल में सेट किया जाए:

Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure

नए व्यवहार को लागू करने वाले ब्राउज़र, SameSite वैल्यू के साथ कुकी सेट करते हैं. नए व्यवहार को लागू न करने वाले ब्राउज़र, उस वैल्यू को अनदेखा करते हैं और 3pcookie-legacy कुकी सेट करते हैं. शामिल की गई कुकी को प्रोसेस करते समय, आपकी साइट को सबसे पहले नई स्टाइल की कुकी की मौजूदगी की जांच करनी चाहिए. इसके बाद, अगर उसे नई कुकी नहीं मिलती है, तो उसे लेगसी कुकी का इस्तेमाल करना चाहिए.

यहां दिए गए उदाहरण में, Node.js में Express फ़्रेमवर्क और उसके cookie-parser मिडलवेयर का इस्तेमाल करके, ऐसा करने का तरीका बताया गया है:

const express = require('express');
const cp = require('cookie-parser');
const app = express();
app.use(cp());

app.get('/set', (req, res) => {
  // Set the new style cookie
  res.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
  // And set the same value in the legacy cookie
  res.cookie('3pcookie-legacy', 'value', { secure: true });
  res.end();
});

app.get('/', (req, res) => {
  let cookieVal = null;

  if (req.cookies['3pcookie']) {
    // check the new style cookie first
    cookieVal = req.cookies['3pcookie'];
  } else if (req.cookies['3pcookie-legacy']) {
    // otherwise fall back to the legacy cookie
    cookieVal = req.cookies['3pcookie-legacy'];
  }

  res.end();
});

app.listen(process.env.PORT);

इस तरीके के लिए, आपको फ़ालतू कुकी सेट करने और कुकी को सेट करने और पढ़ने, दोनों के समय बदलाव करने के लिए ज़्यादा काम करना होगा. हालांकि, इससे सभी ब्राउज़र कवर हो जाने चाहिए. साथ ही, तीसरे पक्ष की कुकी काम करती रहनी चाहिए.

इसके अलावा, Set-Cookie हेडर भेजे जाने पर, उपयोगकर्ता एजेंट स्ट्रिंग का इस्तेमाल करके क्लाइंट का पता लगाया जा सकता है. साथ काम नहीं करने वाले क्लाइंट की सूची देखें, और अपने प्लैटफ़ॉर्म के लिए, उपयोगकर्ता एजेंट का पता लगाने वाली सही लाइब्रेरी का इस्तेमाल करें. उदाहरण के लिए, Node.js पर ua-parser-js लाइब्रेरी. इस तरीके के लिए, आपको सिर्फ़ एक बदलाव करना होगा. हालांकि, उपयोगकर्ता एजेंट स्निफ़िंग से, सभी प्रभावित उपयोगकर्ताओं का पता नहीं चल सकता है.

भाषाओं, लाइब्रेरी, और फ़्रेमवर्क में SameSite=None की सुविधा

ज़्यादातर भाषाओं और लाइब्रेरी में, कुकी के लिए SameSite एट्रिब्यूट की सुविधा मौजूद है. हालांकि, SameSite=None को जोड़े जाने की सुविधा अब भी नई है. इसलिए, फ़िलहाल आपको कुछ स्टैंडर्ड व्यवहार के लिए वैकल्पिक तरीका अपनाना पड़ सकता है. इन व्यवहारों के बारे में, GitHub पर मौजूद SameSite के उदाहरणों वाली रिपॉज़िटरी में बताया गया है.

सहायता पाना

वेब पर हर जगह कुकी का इस्तेमाल किया जाता है. साथ ही, ऐसा बहुत कम होता है कि किसी डेवलपमेंट टीम को यह पूरी जानकारी हो कि उनकी साइट, कुकी कहां सेट करती है और उनका इस्तेमाल कहां करती है. खास तौर पर, अलग-अलग साइटों पर इस्तेमाल के उदाहरणों में. जब आपको कोई समस्या आती है, तो ऐसा हो सकता है कि किसी और को भी यह समस्या पहली बार आई हो. इसलिए, बेझिझक संपर्क करें: