flawopen.com/संदर्भ/JWT बनाम HttpOnly कुकीज़
localStorage में JWT बनाम HttpOnly कुकीज़: कौन ज़्यादा सुरक्षित?
कई वेब ऐप्लिकेशन के लिए, सर्वर द्वारा प्रबंधित सत्र को HttpOnly कुकी से भेजना एक अच्छा शुरुआती विकल्प है। JavaScript उस कुकी को पढ़ नहीं सकता, इसलिए टोकन निकालना कठिन होता है; लेकिन इससे XSS निष्प्रभावी नहीं होता। उसी origin में चलने वाला इंजेक्ट किया गया कोड प्रमाणित अनुरोध भेज सकता है और पेज के लिए उपलब्ध डेटा पढ़ सकता है।
सुरक्षा के समझौते
| संग्रहण / भेजना | XSS जोखिम | CSRF व्यवहार | निरस्तीकरण |
|---|---|---|---|
localStorage bearer token | उसी origin का JavaScript इसे पढ़ सकता है; XSS इसे चुरा सकता है या उपयोगकर्ता की तरह कार्रवाई कर सकता है। | cross-site अनुरोध में अपने-आप नहीं जुड़ता; XSS और client-side CSRF का जोखिम बना रहता है। | revocation न जाँची जाए तो self-contained JWT समाप्ति तक मान्य रह सकता है। |
HttpOnly cookie | JavaScript कुकी मान नहीं पढ़ सकता; XSS फिर भी प्रमाणित अनुरोध भेज सकता है। | कुकी नियमों के अनुसार अपने-आप भेजा जाता है; SameSite CSRF की केवल एक परत है। | अपारदर्शी सत्र सर्वर पर अमान्य हो सकता है; JWT कुकी के लिए अलग revocation नीति चाहिए। |
अनुशंसित संरचना
- ✓सत्र पहचानकर्ता
HttpOnly; Secure; SameSite=Laxकुकीज़ में रखें। - ✓स्थायी प्रमाणीकरण टोकन को
localStorageयाsessionStorageमें रखने से बचें।
टोकन प्रारूप, संग्रहण और सत्र स्थिति को अलग समझें
JWT टोकन का प्रारूप है; localStorage और कुकी ब्राउज़र में संग्रहण और भेजने के तरीके हैं। JWT इनमें से किसी में रखा जा सकता है। कुकी में रखा अपारदर्शी सत्र पहचानकर्ता आम तौर पर सर्वर पर रखी सत्र स्थिति दर्शाता है। “JWT या कुकी” समान विकल्पों के बीच सीधी तुलना नहीं है।
हर विकल्प से क्या बदलता है
ब्राउज़र localStorage के मानों को cross-site अनुरोधों में अपने-आप नहीं जोड़ता, लेकिन उसी origin का XSS bearer टोकन पढ़ सकता है या ऐप के माध्यम से कार्रवाई कर सकता है। कुकी ब्राउज़र नियमों के अनुसार अपने-आप भेजी जाती है। HttpOnly मान को JavaScript से छिपाता है, पर इंजेक्ट किए गए कोड को लॉग-इन पेज इस्तेमाल करने से नहीं रोकता। SameSite=Lax CSRF सुरक्षा की एक परत है, पूरी गारंटी नहीं: सुरक्षित विधि वाली top-level navigation और same-site अनुरोध भी मायने रखते हैं। GET से स्थिति न बदलें; सत्यापित token और/या Origin जाँच जैसी उपयुक्त CSRF सुरक्षा लगाएँ।
निरस्तीकरण सर्वर स्थिति और टोकन सत्यापन पर निर्भर है, संग्रहण स्थान पर नहीं। सर्वर सत्र का रिकॉर्ड हटाकर उसे अमान्य किया जा सकता है। revocation जाँची न जाए तो self-contained JWT समाप्ति तक मान्य रह सकता है; छोटी अवधि इस समय को घटाती है, समाप्त नहीं करती।
व्यावहारिक शुरुआती व्यवस्था
- ✓अपने वेब ऐप में, अनुकूल होने पर, अपारदर्शी server-side session या Backend-for-Frontend (BFF) चुनें।
- ✓सत्र कुकी में
Secure,HttpOnly, सोच-समझकर चुना गयाSameSite,Path=/रखें; संभव हो तोDomainन दें और__Host-पर विचार करें। - ✓स्थिति बदलने वाले अनुरोधों पर खतरे के मॉडल के अनुसार CSRF token और/या Origin validation लगाएँ;
GETसे स्थिति न बदलें। - ✓ब्राउज़र JWT आवश्यक हो तो अवधि कम रखें, logout/revocation नीति तय करें और XSS रोकें। कुकी में रखना authorization जाँच का विकल्प नहीं है।