SameSite कुकी रेसिपी

Rowan Merewood

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

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

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

ब्राउज़र सहायता

  • 51
  • 16
  • 60
  • 13

सोर्स

क्रॉस-साइट या तीसरे पक्ष की कुकी के लिए इस्तेमाल के उदाहरण

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

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

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

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

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

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

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

सभी साइटों पर "असुरक्षित" अनुरोध

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

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

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

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

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

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

वेबव्यू में मौजूद कॉन्टेंट

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

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 कुकी सेट कर देते हैं. शामिल की गई कुकी को प्रोसेस करते समय, आपकी साइट को पहले जांच करनी चाहिए कि कुकी की नई स्टाइल मौजूद है या नहीं. इसके बाद, अगर नई कुकी नहीं मिलती है, तो लेगसी कुकी पर वापस चला जाना चाहिए.

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

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 उदाहरण में जानकारी दी गई है.

सहायता पाना

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