स्कीमफ़ुल सेम-साइट

"सेम-साइट" की परिभाषा में यूआरएल स्कीम को शामिल करने के हिसाब से बदलाव किए जा रहे हैं. इसलिए, किसी साइट के एचटीटीपी और एचटीटीपीएस वर्शन के बीच के लिंक, अब क्रॉस-साइट अनुरोधों के तौर पर गिने जाते हैं. जहां संभव हो वहां होने वाली समस्याओं से बचने के लिए, डिफ़ॉल्ट रूप से एचटीटीपीएस पर अपग्रेड करें. इसके अलावा, SameSite एट्रिब्यूट की वैल्यू के बारे में जानने के लिए आगे पढ़ें.

स्टीवन बिंजलर

रोवन मेरेवुड

सेम-साइट, किसी (वेब) साइट की परिभाषा को सिर्फ़ रजिस्टर किए जा सकने वाले डोमेन से स्कीम और रजिस्ट्रेशन वाले डोमेन में बदलता है. ज़्यादा जानकारी और उदाहरण देखने के लिए, "same-site" और "same-origin") को समझना देखें.

अच्छी खबर यह है: अगर आपकी वेबसाइट पहले ही पूरी तरह से एचटीटीपीएस पर अपग्रेड कर दी गई है, तो आपको किसी भी चीज़ की चिंता करने की ज़रूरत नहीं है. आपके लिए कोई बदलाव नहीं होगा.

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

Chrome और Firefox, दोनों में जांच के लिए इन बदलावों को चालू किया जा सकता है.

• Chrome 86 से, about://flags/#schemeful-same-site को चालू करें. Chrome की स्थिति वाले पेज पर प्रोग्रेस ट्रैक करें.
• Firefox 79 से, about:config के ज़रिए network.cookie.sameSite.schemeful को true पर सेट करें. Bigzilla समस्या के ज़रिए प्रोग्रेस ट्रैक करें.

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

क्रॉस-स्कीम की सामान्य स्थितियां

नेविगेशन

किसी वेबसाइट के क्रॉस-स्कीम वर्शन के बीच नेविगेट करने (उदाहरण के लिए, http://site.example से https://site.example पर लिंक करने) से पहले SameSite=Strict कुकी भेजी जा सकती थीं. इसे अब क्रॉस-साइट नेविगेशन के तौर पर माना जाता है. इसका मतलब है कि SameSite=Strict कुकी ब्लॉक कर दी जाएंगी.

सबरिसॉर्स लोड हो रहे हैं

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

सबरिसॉर्स के उदाहरणों में इमेज, iframe, और XHR या फ़ेच की मदद से किए गए नेटवर्क अनुरोध शामिल हैं.

किसी पेज पर क्रॉस-स्कीम सबरिसॉर्स लोड करने से, पहले SameSite=Strict या SameSite=Lax कुकी भेजने या सेट करने की अनुमति मिलती थी. अब इसका इस्तेमाल तीसरे पक्ष या क्रॉस-साइट के किसी भी दूसरे सबरिसॉर्स की तरह ही किया जाता है. इसका मतलब है कि अब कोई भी SameSite=Strict या SameSite=Lax कुकी ब्लॉक कर दी जाएगी.

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

फ़ॉर्म पोस्ट करना

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

सबरिसॉर्स की तरह ही, अगर अनुरोध किसी सुरक्षित, जैसे कि एचटीटीपीएस से लेकर असुरक्षित, एचटीटीपी पर जा रहा है, तो इन अनुरोधों पर कॉन्टेक्स्ट की सभी कुकी को ब्लॉक कर दिया जाएगा. इसकी वजह यह है कि तीसरे पक्ष या क्रॉस-साइट कुकी के लिए, Secure की ज़रूरत होती है.

मैं अपनी साइट की जांच कैसे करूं?

डेवलपर टूल और मैसेज सेवा, Chrome और Firefox में उपलब्ध है.

Chrome 86 से, DevTool में मौजूद समस्या वाले टैब में, स्कीमफ़ुल सेम-साइट से जुड़ी समस्याएं शामिल होंगी. आपको अपनी साइट में, हाइलाइट की गई ये समस्याएं दिख सकती हैं.

नेविगेशन से जुड़ी समस्याएं:

• "एक ही साइट के अनुरोधों पर कुकी भेजना जारी रखने के लिए, पूरी तरह से एचटीटीपीएस पर माइग्रेट करें"—यह चेतावनी कि Chrome के आने वाले वर्शन में कुकी को ब्लॉक कर दिया जाएगा.
• "एक ही साइट के अनुरोधों पर कुकी भेजने के लिए, पूरी तरह से एचटीटीपीएस पर माइग्रेट करें"—यह एक चेतावनी है कि कुकी ब्लॉक कर दी गई है.

सबरिसॉर्स लोड होने से जुड़ी समस्याएं:

• "एक ही साइट के सबरिसॉर्स पर कुकी भेजना जारी रखने के लिए, पूरी तरह से एचटीटीपीएस पर माइग्रेट करें" या "एक ही साइट के सबरिसॉर्स से कुकी सेट करने की अनुमति देते रहने के लिए, पूरी तरह से एचटीटीपीएस पर माइग्रेट करें"—चेतावनी कि Chrome के आने वाले वर्शन में कुकी को ब्लॉक किया जाएगा.
• "एक ही साइट के सबरिसॉर्स पर कुकी भेजने के लिए, पूरी तरह से एचटीटीपीएस पर माइग्रेट करें" या "एक ही साइट के सबरिसॉर्स से कुकी को सेट करने की अनुमति देने के लिए, पूरी तरह से एचटीटीपीएस पर माइग्रेट करें"—इस तरह की चेतावनियां कि कुकी ब्लॉक की गई है. फ़ॉर्म को पोस्ट करते समय भी, बाद वाली चेतावनी दिख सकती है.

ज़्यादा जानकारी के लिए, सेम-साइट वाली स्कीमफ़ुल के लिए, जांच और डीबग करने से जुड़ी सलाह देखें.

Firefox 79 से, about:config के ज़रिए network.cookie.sameSite.schemeful को true पर सेट करने पर, कंसोल स्कीमफ़ुल सेम-साइट समस्याओं के लिए मैसेज दिखाएगा. आपको अपनी साइट पर यह जानकारी दिख सकती है:

• "कुकी cookie_name जल्द ही, http://site.example/ के मुकाबले क्रॉस-साइट कुकी के तौर पर मानी जाएगी, क्योंकि स्कीम मेल नहीं खाती."
• "कुकी cookie_name को http://site.example/ के मुकाबले क्रॉस-साइट माना गया है, क्योंकि स्कीम मेल नहीं खाती."

अक्सर पूछे जाने वाले सवाल

मेरी साइट पहले से ही एचटीटीपीएस पर पूरी तरह से उपलब्ध है, फिर भी मुझे अपने ब्राउज़र के DevTools में समस्याएं क्यों दिख रही हैं?

ऐसा हो सकता है कि आपके कुछ लिंक और सबरिसॉर्स अब भी असुरक्षित यूआरएल पर ले जाते हों.

इस समस्या को ठीक करने का एक तरीका यह है कि आप एचटीटीपी स्ट्रिक्ट-ट्रांसपोर्ट-सिक्योरिटी (एचएसटीएस) और includeSubDomain डायरेक्टिव का इस्तेमाल करें. HSTS + includeSubDomain के साथ, अगर आपके किसी पेज में गलती से कोई असुरक्षित लिंक शामिल हो जाता है, तो ब्राउज़र इसके बजाय अपने आप सुरक्षित वर्शन का इस्तेमाल करेगा.

अगर मैं एचटीटीपीएस पर अपग्रेड न कर सकूं, तो क्या होगा?

हमारा सुझाव है कि अपने उपयोगकर्ताओं की सुरक्षा के लिए, आप अपनी साइट को पूरी तरह से एचटीटीपीएस पर अपग्रेड करें. हालांकि, अगर ऐसा नहीं हो पा रहा है, तो हमारा सुझाव है कि आप सर्वर देने वाली संस्था से संपर्क करके देखें कि वे यह विकल्प दे सकते हैं या नहीं. अगर आप खुद होस्ट करते हैं, तो Let's Encrypt से ऐसे कई टूल मिलते हैं जिनकी मदद से सर्टिफ़िकेट को इंस्टॉल और कॉन्फ़िगर किया जा सकता है. अपनी साइट को एचटीटीपीएस कनेक्शन देने वाले किसी सीडीएन या दूसरे प्रॉक्सी के ज़रिए भी ट्रांसफ़र किया जा सकता है.

अगर अब भी ऐसा नहीं किया जा सकता, तो कुकी पर SameSite की सुरक्षा को कम करने की कोशिश करें.

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

अगर मैंने SameSite एट्रिब्यूट की जानकारी नहीं दी है, तो इससे मेरी कुकी पर क्या असर पड़ेगा?

बिना SameSite एट्रिब्यूट वाली कुकी को उसी तरह माना जाता है जैसे उन्होंने SameSite=Lax को बताया हो. साथ ही, इन कुकी पर भी यही क्रॉस-स्कीम लागू होती है. ध्यान दें कि असुरक्षित तरीकों का अस्थायी अपवाद अब भी लागू होता है. ज़्यादा जानकारी के लिए, Chromium के SameSite से जुड़े अक्सर पूछे जाने वाले सवाल में Lax + POST के बाद लागू होने वाली पाबंदियां देखें.

WebSockets कैसे प्रभावित होते हैं?

अगर WebSocket कनेक्शन, पेज की सुरक्षा के बराबर हैं, तब भी उन्हें एक ही साइट माना जाएगा.

एक ही साइट के लिए:

• https:// से wss:// कनेक्शन
• http:// से ws:// कनेक्शन

क्रॉस-साइट:

• http:// से wss:// कनेक्शन
• https:// से ws:// कनेक्शन

Unsplash पर जूलिसा कैपडेविला की फ़ोटो