Set-Cookie हेडर सफलतापूर्वक सेट हो गया लेकिन ब्राउज़र ने मेरी Cookie क्यों नहीं सहेजी?
यह सबसे आम समस्या है, ब्राउज़र सक्रिय रूप से त्रुटि की रिपोर्ट नहीं करेगा बल्कि गैर-अनुपालक Cookie को चुपचाप छोड़ देगा। सामान्य कारणों में शामिल हैं: SameSite=None में Secure की कमी, Secure Cookie HTTP पेज पर सेट की गई (localhost को छोड़कर), __Host-/__Secure- उपसर्ग बाधाएं पूरी नहीं हुईं, Domain/Path मेल नहीं खाते, 4KB आकार सीमा से अधिक, Max-Age शून्य या नकारात्मक। सिफारिश है कि पहले Set-Cookie को इस टूल में पेस्ट करें, विशिष्ट कारण पहचानने के लिए चेतावनी बैज देखें, फिर Chrome DevTools → Application → Cookies खोलें, संबंधित डोमेन के तहत देखें कि क्या पीला चेतावनी त्रिभुज है, होवर करने पर विशिष्ट अस्वीकृति कारण दिखाई देगा।
SameSite के Strict, Lax, None में वास्तव में क्या अंतर है? कब किसका उपयोग करें?
Strict क्रॉस-साइट भेजने की पूरी तरह से अनुमति नहीं देता, सबसे सुरक्षित लेकिन बाहरी साइट के लिंक से क्लिक करने पर उपयोगकर्ता लॉग आउट दिखाई देगा, भुगतान/पासवर्ड बदलने जैसे संवेदनशील संचालन Cookie के लिए उपयुक्त। Lax Chrome 80+ का डिफ़ॉल्ट मान है, जब उपयोगकर्ता बाहरी लिंक से शीर्ष-स्तरीय GET नेविगेशन के माध्यम से आपकी वेबसाइट पर वापस आते हैं तो ले जाने की अनुमति देता है (बाहरी लिंक पर क्लिक करके आपकी साइट पर वापस आना), लेकिन iframe/img/script/XHR/POST फॉर्म जैसे उप-संसाधनों में नहीं ले जाता, अधिकांश परिदृश्यों के लिए अनुशंसित मान है। None सभी क्रॉस-साइट परिदृश्यों में भेजने की अनुमति देता है (SSO सिंगल साइन-ऑन, तृतीय-पक्ष iframe एम्बेड, क्रॉस-साइट API कॉल के लिए उपयोग किया जाता है), लेकिन एक साथ Secure सेट करना होगा, अन्यथा ब्राउज़र सीधे अस्वीकार कर देगा।
SameSite=None को Secure के साथ जोड़ना क्यों अनिवार्य है?
यह नियम Chrome द्वारा संस्करण 80 (फरवरी 2020) से अनिवार्य रूप से लागू किया गया है, Firefox, Edge, Safari ने भी इसका अनुसरण किया है। क्योंकि SameSite=None स्पष्ट रूप से Cookie को क्रॉस-साइट भेजने की अनुमति देता है, हमलावर क्रॉस-साइट परिदृश्य में CSRF हमले करना या स्नूपिंग करना आसान हो जाता है, जोखिम कम करने के लिए Secure (HTTPS एन्क्रिप्टेड ट्रांसमिशन) के साथ जोड़ना अनिवार्य है। यदि आपकी SameSite=None Cookie HTTP के तहत सेट की जाती है, तो ब्राउज़र बिना स्टोर किए सीधे छोड़ देगा। यह टूल SameSite=None में Secure की कमी के संयोजन का पता लगाकर लाल चेतावनी देगा।
Max-Age और Expires में से किसका उपयोग करें? क्या अंतर है?
Max-Age का प्राथमिकता से उपयोग करें। Max-Age सापेक्ष समय है (कितने सेकंड बाद समाप्त), क्लाइंट घड़ी पर निर्भर नहीं करता, ब्राउज़र प्राप्त करने के बाद उलटी गिनती शुरू कर देता है; Expires पूर्ण समय बिंदु है, जो उपयोगकर्ता के कंप्यूटर के स्थानीय समय पर निर्भर करता है (उपयोगकर्ता घड़ी को 1970 में बदल दे तो Cookie तुरंत समाप्त हो जाएगी)। जब दोनों एक साथ मौजूद हों तो Max-Age की प्राथमिकता अधिक होती है (RFC 6265 स्पष्ट रूप से निर्धारित करता है)। यदि दोनों सेट नहीं हैं, तो Cookie「सत्र Cookie」बन जाती है, ब्राउज़र बंद होने पर समाप्त हो जाती है। यह टूल Expires सेट करने लेकिन Max-Age सेट न करने के मामले में सुझाव देगा, Max-Age जोड़ने की सिफारिश करेगा। ध्यान दें कि Max-Age की इकाई सेकंड है मिलीसेकंड नहीं।
Path=/ और Path सेट न करने में क्या अंतर है?
Path यह निर्धारित करता है कि ब्राउज़र किन URL पथों के अनुरोधों में यह Cookie ले जाएगा। Path सेट न करने पर, ब्राउज़र डिफ़ॉल्ट रूप से「रिस्पॉन्स URL के अंतिम खंड को हटाने के बाद का पथ」उपयोग करता है, उदाहरण के लिए /api/user/login से Cookie सेट करते समय डिफ़ॉल्ट Path /api/user/ है, तो / पथ और /order/ के तहत अनुरोध इस Cookie को नहीं ले जाएंगे। स्पष्ट रूप से Path=/ सेट करने से Cookie पूरी साइट पर प्रभावी हो सकती है। ध्यान दें कि Path मिलान उपसर्ग मिलान है, Path=/api /api/, /api/user, /api/v2/abc आदि से भी मेल खाएगा। __Host- उपसर्ग Cookie के लिए Path=/ अनिवार्य है।
Domain की शुरुआत में डॉट (जैसे .example.com) और बिना डॉट के क्या अंतर है?
आधुनिक ब्राउज़र (Chrome, Firefox, Edge, Safari के हाल के संस्करण) में दोनों समतुल्य हो गए हैं, दोनों Cookie को example.com और इसके सभी उपडोमेन (a.example.com, b.c.example.com) पर प्रभावी बनाएंगे। डॉट से शुरुआत RFC 2109 युग की पुरानी लेखन शैली है, RFC 6265 ने स्पष्ट रूप से अग्रणी डॉट को अनदेखा करने का निर्धारण किया है। हालांकि, पठनीयता के लिए बिना डॉट के रूप में लिखने की सिफारिश की जाती है। यह टूल डोमेन के अग्रणी डॉट वाले मामले के लिए सुझाव देगा (त्रुटि नहीं है, लेकिन ऐतिहासिक विरासत लेखन शैली है)। ध्यान दें: Domain सेट न करने पर Cookie केवल वर्तमान होस्ट पर प्रभावी होती है (उपडोमेन नहीं ले जाते), Domain सेट करने के बाद उपडोमेन पर प्रभावी होगी।
__Host- और __Secure- उपसर्ग क्या हैं? क्या उपसर्ग नहीं लिख सकते?
ये RFC 6265bis द्वारा पेश किए गए Cookie नाम सुरक्षा उपसर्ग हैं, जिनका उपयोग उच्च-सुरक्षा Cookie के लिए कठोर बाधाएं जोड़ने के लिए किया जाता है: जब ब्राउज़र देखता है कि Cookie नाम __Host- से शुरू होता है, तो यह अनिवार्य रूप से आवश्यक करेगा कि एक साथ Secure, Path=/ सेट हों, Domain सेट न किया जाए, किसी भी शर्त को पूरा न करने पर सीधे स्टोर करने से इनकार कर देगा; __Secure- उपसर्ग के लिए Secure सेट करना अनिवार्य है, अन्य एट्रिब्यूट कॉन्फ़िगर किए जा सकते हैं। उपसर्ग न लिखने से भी काम चल सकता है (अधिकांश Cookie उपसर्ग का उपयोग नहीं करतीं), लेकिन सत्र पहचानकर्ता, प्राधिकरण Token जैसी उच्च-सुरक्षा Cookie के लिए __Host- उपसर्ग का उपयोग करने की दृढ़ता से सिफारिश की जाती है, क्योंकि यह उपडोमेन/पथ स्तर की Cookie इंजेक्शन हमलों को रोक सकता है। यह टूल दोनों प्रकार के उपसर्गों की अनुपालना की स्वचालित रूप से जांच करेगा।
क्या HttpOnly Cookie वास्तव में सुरक्षित है? क्या यह XSS और CSRF को रोकती है?
HttpOnly JavaScript को document.cookie के माध्यम से Cookie मान पढ़ने से रोक सकता है, <strong>XSS सत्र चोरी को कम करने</strong> के लिए एक महत्वपूर्ण रक्षा पंक्ति है, लेकिन सर्व-उपचार नहीं है: XSS हमलावर अभी भी उपयोगकर्ता के ब्राउज़र में अनुरोध भेज सकता है (अनुरोध स्वचालित रूप से Cookie ले जाता है) संचालन करने के लिए (यह CSRF का दायरा है); HttpOnly भी CSRF हमले से रक्षा नहीं कर सकता (SameSite या CSRF Token के संयोजन की आवश्यकता है)। केवल जब HttpOnly+Secure+SameSite=Lax/Strict तीनों का एक साथ उपयोग किया जाता है तभी बुनियादी सुरक्षा स्तर प्राप्त होता है। संवेदनशील Cookie (session, JWT, access_token) HttpOnly होनी चाहिए, आवश्यक न होने पर फ्रंट-एंड JS को पढ़ने न दें। यह टूल HttpOnly की कमी वाली Cookie पर चेतावनी देगा।
Partitioned (CHIPS) Cookie क्या है? कब उपयोग करने की आवश्यकता है?
Partitioned Chrome द्वारा तृतीय-पक्ष Cookie की समाप्ति का सामना करने के लिए पेश किया गया नया एट्रिब्यूट है, जिसका पूरा नाम Cookies Having Independent Partitioned State (CHIPS) है। पारंपरिक तृतीय-पक्ष Cookie (जैसे विज्ञापन/एम्बेड सेवा द्वारा कई साइटों पर सेट की गई Cookie) वैश्विक रूप से साझा की जाती थीं, जिनका उपयोग क्रॉस-साइट उपयोगकर्ता ट्रैकिंग के लिए किया जाता था। Partitioned जोड़ने के बाद, ब्राउज़र उस तृतीय-पक्ष Cookie को शीर्ष-स्तरीय साइट के अनुसार अलग-अलग स्टोर करेगा: उपयोगकर्ता द्वारा साइट A और साइट B पर देखी गई तृतीय-पक्ष Cookie पूरी तरह से स्वतंत्र हैं, क्रॉस-साइट पहचान साझा नहीं कर सकतीं। उपयोग के परिदृश्य: एम्बेडेड वीडियो/मैप/भुगतान घटक, तृतीय-पक्ष ग्राहक सेवा प्लगइन, क्रॉस-साइट SSO iframe एम्बेड। Partitioned का उपयोग करते समय एक साथ Secure सेट करना होगा, __Host- उपसर्ग के साथ उपयोग करने की सिफारिश की जाती है।
एक Cookie अधिकतम कितना डेटा स्टोर कर सकती है? प्रति डोमेन कितनी रख सकते हैं?
RFC 6265 के अनुसार, ब्राउज़र प्रति Cookie कम से कम 4096 बाइट का समर्थन करते हैं (नाम, मान और एट्रिब्यूट सहित), प्रमुख ब्राउज़र (Chrome/Firefox/Safari/Edge) सभी इस सीमा का पालन करते हैं, अतिरिक्त भाग को चुपचाप काट दिया जाएगा या छोड़ दिया जाएगा। संख्या सीमाएं ब्राउज़र के अनुसार भिन्न होती हैं: Chrome प्रति डोमेन लगभग 180, Firefox लगभग 150, Safari लगभग 600 (और ITP की सात दिन की सफाई नीति से प्रभावित), सीमा से अधिक होने पर ब्राउज़र LRU रणनीति के अनुसार सबसे पुरानी Cookie को हटा देगा। सिफारिश है कि Cookie केवल सत्र पहचानकर्ता स्टोर करें, बड़े व्यावसायिक डेटा को Cookie में न रखें (व्यावसायिक डेटा localStorage या सर्वर सत्र में रखें)।
क्या Chrome DevTools से सीधे Set-Cookie कॉपी करके पार्स करने का समर्थन है? क्या मैन्युअल रूप से उपसर्ग हटाने की आवश्यकता है?
पूरी तरह से समर्थन है, मैन्युअल प्रसंस्करण की आवश्यकता नहीं है। आप Chrome DevTools → नेटवर्क पैनल में लक्षित अनुरोध पर क्लिक कर सकते हैं, Response Headers क्षेत्र में Set-Cookie के मान पर राइट-क्लिक करके सीधे कॉपी कर सकते हैं (कई पंक्तियों के लिए, Ctrl/⌘+क्लिक करके बहु-चयन करें या पूरा भाग कॉपी करें), इस टूल के इनपुट क्षेत्र में पेस्ट करें बस। टूल स्वचालित रूप से प्रत्येक पंक्ति की शुरुआत में Set-Cookie: उपसर्ग हटा देगा (केस-असंवेदी), स्वचालित रूप से पंक्ति के आरंभ और अंत के रिक्त स्थान को प्रोसेस करेगा, Expires तिथि में निहित अल्पविराम, अर्धविराम जैसे विशेष वर्णों को सही ढंग से संभालेगा, और दोहरे उद्धरण चिह्नों वाले Cookie मानों को भी सही ढंग से संभाल सकता है।
Cookie मान में गैर-ASCII या विशेष वर्ण %XX रूप में क्यों हो जाते हैं?
RFC 6265 की आवश्यकता है कि Cookie मान केवल ASCII वर्ण सेट के सुरक्षित उपसमुच्चय का उपयोग कर सकते हैं, सीधे गैर-ASCII वर्ण, रिक्त स्थान, अल्पविराम, अर्धविराम आदि शामिल नहीं कर सकते। कई सर्वर-साइड फ्रेमवर्क Cookie सेट करते समय गैर-ASCII वर्णों के लिए स्वचालित रूप से URL एन्कोडिंग (encodeURIComponent/Percent-encoding) करते हैं, उदाहरण के लिए हिंदी पाठ को %XX रूप में एन्कोड किया जाएगा। ब्राउज़र वापस भेजते समय भी एन्कोडिंग रूप बनाए रखता है। जब यह टूल पता लगाता है कि मान में %XX एन्कोडिंग है, तो मूल मान के पास हरे तीर से decodeURIComponent डिकोड के बाद मूल पाठ स्वचालित रूप से प्रदर्शित करेगा, ताकि आप वास्तविक सामग्री आसानी से देख सकें।
Set-Cookie और Cookie रिक्वेस्ट हेडर में क्या अंतर है?
दोनों हेडर पूरी तरह से अलग दिशा के हैं: Set-Cookie रिस्पॉन्स हेडर है (सर्वर → ब्राउज़र), केवल रिस्पॉन्स में प्रकट होता है, कई बार प्रकट हो सकता है, प्रत्येक बार एक Cookie सेट करता है, जिसमें पूर्ण एट्रिब्यूट (Secure/HttpOnly/Path/Domain आदि) होते हैं; Cookie रिक्वेस्ट हेडर है (ब्राउज़र → सर्वर), प्रत्येक अनुरोध में केवल एक बार प्रकट होता है, अंदर वर्तमान में स्कोप से मेल खाने वाली सभी Cookie के फ्लैट name=value युग्म होते हैं (name1=v1; name2=v2), इसमें बिल्कुल भी एट्रिब्यूट जानकारी नहीं होती। मतलब सर्वर अनुरोध से यह नहीं जान सकता कि किसी Cookie में HttpOnly या Secure सेट है या नहीं, एट्रिब्यूट जानकारी केवल ब्राउज़र ही स्थानीय रूप से स्टोर करता है। Cookie रिक्वेस्ट हेडर पार्स करने के लिए कृपया संबंधित <a href='/network/http-cookie-parser/'>Cookie रिक्वेस्ट हेडर पार्सर</a> का उपयोग करें।
Safari में मेरी Cookie कुछ दिनों बाद क्यों गायब हो जाती है?
यह Safari का इंटेलिजेंट ट्रैकिंग प्रिवेंशन (ITP: Intelligent Tracking Prevention) तंत्र कार्य कर रहा है। ITP 2.1 से, यदि उपयोगकर्ता 7 दिनों के भीतर उस डोमेन से सीधे इंटरैक्ट नहीं करता (अर्थात् उस डोमेन की साइट पर सीधे नहीं गया), तो Safari उस डोमेन के अंतर्गत सभी Cookie और साइट डेटा को साफ़ कर देगा, चाहे Max-Age/Expires कितना भी लंबा सेट किया हो। यह तृतीय-पक्ष एम्बेड सेवाओं को सबसे अधिक प्रभावित करता है, मुख्य साइट की Cookie पर उपयोगकर्ता के निरंतर एक्सेस के तहत कोई प्रभाव नहीं पड़ता। इसके अलावा Safari तृतीय-पक्ष Cookie पर Chrome की तुलना में भी सख्त प्रतिबंध लगाता है। समाधान में शामिल हैं: Partitioned एट्रिब्यूट का उपयोग करना, Storage Access API के माध्यम से अनुमति का अनुरोध करना, या जब उपयोगकर्ता मुख्य साइट पर जाए तो Cookie को फिर से रीफ्रेश करना। इस टूल के समस्या निवारण अध्याय में अधिक विस्तृत Safari डीबगिंग दिशानिर्देश हैं।
क्या टूल कई Set-Cookie के बल्क पार्सिंग का समर्थन करता है? क्या Cookie सामग्री को सर्वर पर अपलोड करेगा?
बल्क पार्सिंग का समर्थन करता है। इनपुट क्षेत्र कितनी भी पंक्तियों के Set-Cookie पेस्ट करने का समर्थन करता है (उदाहरण के लिए एक बार में पूरे रिस्पॉन्स हेडर को पेस्ट करना), प्रत्येक Set-Cookie को स्वतंत्र क्रमांक के साथ पार्स किया जाएगा, कई एट्रिब्यूट कार्ड प्रत्येक के एट्रिब्यूट और चेतावनियों को अलग-अलग प्रदर्शित करेंगे। सभी पार्सिंग प्रक्रिया पूरी तरह से आपके ब्राउज़र में स्थानीय रूप से पूरी होती है (शुद्ध फ्रंट-एंड JavaScript प्रसंस्करण), Cookie सामग्री किसी भी सर्वर पर अपलोड नहीं की जाती, न ही कोई नेटवर्क अनुरोध भेजा जाता है, आपके द्वारा पेस्ट की गई Session/Token जैसी संवेदनशील जानकारी आपके कंप्यूटर से बाहर नहीं जाएगी, निश्चिंत होकर उपयोग कर सकते हैं।
