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

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

Steven Bingler

Rowan Merewood

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

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

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

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

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

कुकी के लिए डिफ़ॉल्ट तौर पर, 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 के साथ सेट की गई कुकी भेजी जा सकती थीं. अब इसे दूसरी साइट पर पोस्ट करना माना जाता है. सिर्फ़ SameSite=None कुकी भेजी जा सकती हैं. आपको यह स्थिति उन साइटों पर दिख सकती है जो डिफ़ॉल्ट रूप से असुरक्षित वर्शन दिखाती हैं. हालांकि, साइन-इन या चेक-आउट फ़ॉर्म सबमिट करने पर, उपयोगकर्ताओं को सुरक्षित वर्शन पर अपग्रेड कर दिया जाता है.

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

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

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

Chrome 86 से, DevTools के 'समस्या' टैब में , Schemeful Same-Site से जुड़ी समस्याएं शामिल होंगी. आपको अपनी साइट के लिए, हाइलाइट की गई ये समस्याएं दिख सकती हैं.

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

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

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

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

Schemeful Same-Site के लिए, टेस्ट करने और डीबग करने के सुझाव लेख में ज़्यादा जानकारी उपलब्ध है.

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

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

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

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

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

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

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

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

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

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

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

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

WebSockets पर क्या असर पड़ता है?

WebSocket कनेक्शन को अब भी same-site माना जाएगा, अगर वे पेज की तरह ही सुरक्षित हैं.

Same-site:

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

Cross-site:

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