जलद उत्तर: सत्र संग्रहण आणि स्थानिक संग्रहण हे दोन्ही ब्राउझर-आधारित वेब संग्रहण API आहेत जे वेबसाइट्सना वापरकर्त्याच्या उपकरणावर डेटा संग्रहित करण्याची परवानगी देतात, परंतु त्यांची टिकाऊपणा आणि व्याप्तीमध्ये महत्त्वपूर्ण फरक आहे. स्थानिक संग्रहण सत्रे आणि टॅबमध्ये अनिश्चित काळासाठी डेटा टिकवून ठेवतो, तर सत्र संग्रहण ब्राउझर टॅब बंद झाल्यावर डेटा मिटवतो. गोपनीयतेच्या दृष्टिकोनातून, स्थानिक संग्रहण उच्च धोका घेऊन येतो कारण डेटा समाप्तीशिवाय टिकतो, ज्यामुळे ट्रॅकिंग, फिंगरप्रिंटिंग आणि GDPR सारख्या फ्रेमवर्क अंतर्गत नियामक तपासणीसाठी अधिक आकर्षक लक्ष्य बनते.
मुख्य मुद्दे
- स्थानिक संग्रहण अनिश्चित काळासाठी टिकते जोपर्यंत स्पष्टपणे साफ केले जात नाही; सत्र संग्रहण टॅब किंवा विंडो बंद झाल्यावर मिटवले जाते.
- दोन्ही संग्रहण प्रकार क्रॉस-साइट स्क्रिप्टिंग (XSS) हल्ल्यांना असुरक्षित आहेत आणि कोणतीही अंतर्निर्मित एनक्रिप्शन प्रदान करत नाहीत.
- स्थानिक संग्रहण किंवा सत्र संग्रहण डेटा स्वयंचलितपणे सर्व्हरवर पाठवला जात नाही, कुकीजच्या विपरीत, परंतु दोन्हीच त्याच मूळवर चालणाऱ्या कोणत्याही JavaScript द्वारे पूर्णपणे वाचनयोग्य आहेत.
- पृष्ठावर लोड केलेले तृतीय-पक्ष स्क्रिप्ट स्थानिक संग्रहण डेटा वाचू शकतात जर ते त्याच मूळ संदर्भात चालत असतील.
- GDPR अंतर्गत, वापरकर्त्याच्या संमतीशिवाय स्थानिक संग्रहणात अनावश्यक डेटा संग्रहित करणे अनुपालन उल्लंघन आहे, जसे ट्रॅकिंग कुकीज टाकणे.
- संवेदनशील डेटा जसे की प्रमाणीकरण टोकन, पासवर्ड, आणि वैयक्तिक ओळखण्यायोग्य माहिती (PII) कोणत्याही यंत्रणेत अतिरिक्त सुरक्षा स्तरांशिवाय संग्रहित केले जाऊ नये.
- खाजगी/गोपनीय ब्राउझिंग स्थानिक संग्रहण टिकवण्याची मर्यादा घालते परंतु सत्रामध्ये सत्र संग्रहणाच्या धोके समाप्त करत नाही.
- विकासकांनी तात्पुरत्या स्थितीसाठी सत्र संग्रहण प्राधान्य द्यावे, सर्व्हर-साइड सत्र किंवा HttpOnly कुकीज प्रमाणीकरणासाठी वापरावे, आणि संग्रहण संमती व्यवस्थापनासाठी Biscotti CMP सारख्या प्लॅटफॉर्मचा वापर करावा.
सत्र संग्रहण आणि स्थानिक संग्रहण यामध्ये फरक काय आहे?
सत्र संग्रहण आणि स्थानिक संग्रहण हे दोन्ही HTML5 वेब संग्रहण API चा भाग आहेत, परंतु त्यांची टिकाऊपणा आणि टॅब-व्याप्ती वर्तनाद्वारे परिभाषित केलेले वेगळे उद्दिष्टे आहेत.
स्थानिक संग्रहण की-व्हॅल्यू जोड्या कोणत्याही समाप्ती तारखेविना संग्रहित करते. डेटा ब्राउझर पुनःप्रारंभ, प्रणाली पुनःप्रारंभ, आणि निष्क्रियतेच्या अनिश्चित कालावधीत टिकतो जोपर्यंत वापरकर्ता किंवा अनुप्रयोग स्पष्टपणे ते काढत नाही. हे सर्व टॅब आणि विंडोमध्ये समान मूळ (प्रोटोकॉल + डोमेन + पोर्ट) अंतर्गत सामायिक केले जाते. [1][5]
सत्र संग्रहण फक्त पृष्ठ सत्राच्या आयुष्यात डेटा संग्रहित करते. वापरकर्ता टॅब किंवा विंडो बंद केल्यावर डेटा गेला. महत्त्वाचे म्हणजे, प्रत्येक टॅब स्वतःचा स्वतंत्र सत्र संग्रहण ठेवतो, दुसऱ्या टॅबमध्ये समान URL उघडल्यास पहिल्या टॅबचे सत्र संग्रहण डेटा सामायिक होत नाही. [1]
| वैशिष्ट्य | स्थानिक संग्रहण | सत्र संग्रहण |
|---|---|---|
| टिकाऊपणा | अनिश्चित | फक्त टॅब/विंडो आयुष्य |
| टॅबमध्ये सामायिक | होय (समान मूळ) | नाही (प्रत्येक टॅबची स्वतंत्रता) |
| पृष्ठ पुनःलोड टिकवतो | होय | होय |
| टॅब बंद झाल्यावर टिकवतो | होय | नाही |
| संग्रहण क्षमता | ~5-10 MB प्रति मूळ | ~5-10 MB प्रति मूळ |
| सर्व्हरवर प्रसारण | नाही | नाही |
| HttpOnly संरक्षण | उपलब्ध नाही | उपलब्ध नाही |
दोन्ही API समान मूळ धोरणाचे पालन करतात, त्यामुळे https://example.com वर एक पृष्ठ https://otherdomain.com द्वारे सेट केलेले संग्रहण वाचू शकत नाही. [4]
स्थानिक संग्रहणाच्या तुलनेत सत्र संग्रहणामध्ये गोपनीयतेचे धोके आहेत का?
होय, स्थानिक संग्रहण सत्र संग्रहणाच्या तुलनेत महत्त्वपूर्णपणे उच्च गोपनीयतेचे धोके घेऊन येते, मुख्यतः त्याच्या अनिश्चित टिकाऊपणा आणि क्रॉस-टॅब प्रवेशामुळे.
स्थानिक संग्रहणात लिहिलेला डेटा वापरकर्त्याच्या जागरूकतेशिवाय महिन्यांपासून किंवा वर्षांपर्यंत जमा होऊ शकतो. जाहिरातदार आणि विश्लेषण विक्रेत्यांनी ऐतिहासिकरित्या स्थानिक संग्रहणाचा वापर "सुपर-कुकी" म्हणून केला आहे, एक ट्रॅकिंग ओळखकर्ता जो कुकी हटवल्यानंतर टिकतो कारण बहुतेक वापरकर्ते ब्राउझर संग्रहण स्वयंचलितपणे साफ करण्याचा विचार करत नाहीत. सत्र संग्रहण, याउलट, टॅब बंद झाल्यावर स्वतःला नष्ट करते, ज्यामुळे ते ट्रॅकिंग वेक्टरसाठी कमी उपयुक्त बनते.
स्थानिक संग्रहणासाठी अद्वितीय गोपनीयता धोका घटक:
- टिकाऊ ट्रॅकिंग ओळखकर्ते: स्थानिक संग्रहणात संग्रहित एक अद्वितीय ID वापरकर्त्याला अनेक भेटींमध्ये ट्रॅक करू शकते कोणत्याही सर्व्हर-साइड कुकीशिवाय.
- क्रॉस-टॅब डेटा गळती: समान मूळच्या कोणत्याही टॅबमधील कोणतीही स्क्रिप्ट सर्व स्थानिक संग्रहण डेटा वाचू शकते.
- संग्रहण इव्हेंट प्रसारण: स्थानिक संग्रहणातील बदल समान मूळच्या इतर खुल्या टॅबमध्ये
storageइव्हेंटला ट्रिगर करतात, ज्यामुळे क्रॉस-टॅब डेटा समन्वय सक्षम होतो जो वापरकर्ते पाहू शकत नाहीत. [5] - स्वयंचलित समाप्ती नाही: कुकीजच्या विपरीत, ज्यामध्ये
Max-AgeआणिExpiresगुणधर्म असतात, स्थानिक संग्रहणात TTL यंत्रणा नाही.
वेबसाइट्स स्थानिक संग्रहण आणि सत्र संग्रहणाचा वापर करून वापरकर्त्यांना ट्रॅक करू शकतात का?
वेबसाइट्स स्थानिक संग्रहणाचा वापर करून टिकाऊ ट्रॅकिंग करू शकतात. सत्र संग्रहण ट्रॅकिंगसाठी कमी उपयुक्त आहे परंतु तरीही सत्रामध्ये देखरेख धोके निर्माण करते.
एकल JavaScript ओळ, localStorage.setItem('uid', 'abc123'), एक टिकाऊ ओळखकर्ता तयार करते जो कुकी साफ केल्यानंतर टिकतो. या तंत्राला कधी कधी "एव्हरकुकी" किंवा संग्रहण-आधारित पुनःउत्पादन असे म्हटले जाते, हे गोपनीयता संशोधनात दस्तऐवज केले गेले आहे आणि नियामक स्थानिक संग्रहणाला कुकीजप्रमाणेच संमती नियमांखाली अधिकाधिक मानतात.
सत्र संग्रहण एकाच सत्रामध्ये वर्तन ट्रॅक करू शकते (पृष्ठ प्रवाह, फॉर्म इनपुट, नेव्हिगेशन पॅटर्न), परंतु डेटा टॅब बंद झाल्यावर गेला जातो, ज्यामुळे दीर्घकालीन प्रोफाइलिंगसाठी त्याची उपयुक्तता मर्यादित होते.
सत्र संग्रहणाच्या तुलनेत स्थानिक संग्रहणात डेटा किती काळ राहतो?
स्थानिक संग्रहण डेटा स्पष्टपणे मिटवला जातो जोपर्यंत तो वापरकर्त्याद्वारे ब्राउझर संग्रहण साफ केला जात नाही, वेबसाइट localStorage.removeItem() किंवा localStorage.clear() कॉल करत नाही, किंवा ब्राउझर संग्रहण कोटा लागू करत नाही. [2]
सत्र संग्रहण डेटा स्वयंचलितपणे मिटवला जातो जेव्हा टॅब किंवा विंडो बंद होते ज्याने ते तयार केले. हे समान टॅबमध्ये पृष्ठ पुनःलोड टिकवते परंतु नवीन टॅबमध्ये हस्तांतरित होत नाही, अगदी वापरकर्ता काही ब्राउझरमध्ये टॅब डुप्लिकेट केल्यासही. [1]
व्यावहारिक परिणाम: जर एक विकासक स्थानिक संग्रहणात सत्र टोकन संग्रहित करतो तर ते टोकन वापरकर्ता लॉगआउट केल्यानंतर उपकरणावर राहते, जोपर्यंत अनुप्रयोग स्पष्टपणे ते काढत नाही. हे एक सामान्य आणि परिणामकारक चूक आहे.
सत्र संग्रहण स्थानिक संग्रहणापेक्षा अधिक गोपनीय आहे का?
अधिकांश गोपनीयता वापर प्रकरणांसाठी, होय, सत्र संग्रहण अधिक गोपनीयतेचा आदर करणारा पर्याय आहे. टॅब बंद झाल्यावर स्वयंचलितपणे मिटवणे म्हणजे डेटा टिकत नाही, उपकरणे सामायिक करण्यापासून, चोरलेले उपकरणे, किंवा फोरेंसिक विश्लेषणापासून उघडकीस येण्याची कमी शक्यता असते.
तथापि, सत्र संग्रहण अंतर्निहित "गोपनीय" नाही. सक्रिय सत्रामध्ये, ते स्थानिक संग्रहणासारखेच XSS हल्ल्यांना असुरक्षित आहे. कोणतीही इंजेक्ट केलेली स्क्रिप्ट sessionStorage.getItem() कॉल करू शकते आणि डेटा वास्तविक वेळेत बाहेर काढू शकते. [3]
सत्र संग्रहण निवडा जर: डेटा फक्त वर्तमान वापरकर्ता संवादासाठी आवश्यक असेल (उदा., मल्टी-स्टेप फॉर्म स्थिती, एकदाच नेव्हिगेशन टोकन).
स्थानिक संग्रहण निवडा जर: डेटा खरोखरच सत्रांमध्ये टिकवण्याची आवश्यकता असेल (उदा., वापरकर्ता UI प्राधान्ये, असंवेदनशील सेटिंग्ज), आणि याची खात्री करा की त्यात काहीही वैयक्तिक ओळखण्यायोग्य नाही.
स्थानिक संग्रहणात कधीही कोणती वैयक्तिक माहिती संग्रहित केली जाऊ नये?
खालील डेटा श्रेणी स्थानिक संग्रहणात कधीही संग्रहित केली जाऊ नये (आणि सत्र संग्रहणातही अत्यंत काळजीपूर्वक हाताळली जावी): [3]
- प्रमाणीकरण टोकन (JWTs, OAuth टोकन, सत्र ID)
- पासवर्ड किंवा पासवर्ड हॅश
- क्रेडिट कार्ड किंवा पेमेंट माहिती
- सरकारी जारी केलेले ID क्रमांक किंवा सामाजिक सुरक्षा क्रमांक
- ईमेल पत्ते किंवा फोन नंबरांसह संपूर्ण नावे
- वैद्यकीय किंवा आरोग्य रेकॉर्ड
- GDPR अंतर्गत "विशेष श्रेणी" म्हणून वर्गीकृत केलेला कोणताही डेटा (बायोमेट्रिक डेटा, आरोग्य डेटा, राजकीय मते)
स्थानिक संग्रहण आणि सत्र संग्रहणात संग्रहित डेटा स्वयंचलितपणे एनक्रिप्ट केलेला नाही. उपकरणावर भौतिक प्रवेश असलेला कोणताही व्यक्ती, किंवा पृष्ठावर कार्यान्वित होणारी कोणतीही स्क्रिप्ट, ते स्पष्ट मजकूरात वाचू शकते. [3]
तृतीय-पक्ष स्क्रिप्ट स्थानिक संग्रहण डेटा प्रवेश करू शकतात का?
तृतीय-पक्ष स्क्रिप्ट स्थानिक संग्रहण डेटा प्रवेश करू शकतात जर ते होस्ट पृष्ठासमवेत समान मूळमध्ये लोड आणि कार्यान्वित केले जातात. हे एक महत्त्वाचे आणि अनेकदा कमी समजलेले धोका आहे.
जेव्हा एक वेबसाइट तृतीय-पक्ष विश्लेषण किंवा जाहिरात स्क्रिप्ट <script> टॅगद्वारे समाविष्ट करते, तेव्हा ती स्क्रिप्ट होस्ट पृष्ठाच्या मूळ संदर्भात चालते. ती साइटच्या स्थानिक संग्रहणात वाचन आणि लेखन करू शकते. समान मूळ धोरण त्या पृष्ठावर हेतुपुरस्सर किंवा अनवधानाने समाविष्ट केलेल्या स्क्रिप्ट्सपासून संरक्षण करत नाही. [4]
याचा व्यावहारिक अर्थ: जर एक साइट स्थानिक संग्रहणात वापरकर्ता ओळखकर्ता संग्रहित करते आणि तृतीय-पक्ष जाहिरात स्क्रिप्ट देखील लोड करते, तर ती जाहिरात स्क्रिप्ट ओळखकर्ता वाचू शकते आणि त्याला क्रॉस-साइट वर्तन डेटा सह संलग्न करू शकते, वापरकर्त्याच्या ज्ञान किंवा संमतीशिवाय.
हे एक कारण आहे की संमती व्यवस्थापन प्लॅटफॉर्म महत्त्वाचे आहेत. Biscotti CMP वेबसाइट्सना संग्रहण कार्यांसाठी वापरकर्त्याची संमती व्यवस्थापित आणि दस्तऐवज करण्यास सक्षम करते, स्थानिक संग्रहण-आधारित ट्रॅकिंगसह, वेबसाइट्सना GDPR आणि समान फ्रेमवर्क अंतर्गत त्यांच्या कर्तव्यांचे पालन करण्यात मदत करते.
स्थानिक संग्रहण वापरण्याचे GDPR परिणाम काय आहेत?
GDPR अंतर्गत, वैयक्तिक डेटा किंवा ट्रॅकिंग ओळखकर्त्यांचे कोणतेही संग्रहण, तांत्रिक यंत्रणेसाठी, कायदेशीर आधार आवश्यक आहे. स्थानिक संग्रहणाद्वारे अनावश्यक ट्रॅकिंगसाठी, तो आधार बहुतेक वेळा स्पष्ट वापरकर्ता संमती असतो. [2]
युरोपियन डेटा संरक्षण मंडळाने पुष्टी केली आहे की विश्लेषण, जाहिरात, किंवा वापरकर्ता प्रोफाइलिंगसाठी स्थानिक संग्रहणाचा वापर कुकीजप्रमाणेच संमती आवश्यकतांखाली येतो. पूर्व संमतीशिवाय स्थानिक संग्रहणात ट्रॅकिंग ओळखकर्ते टाकणाऱ्या वेबसाइट्सना अनधिकृत कुकीज वापरणाऱ्या वेबसाइट्सप्रमाणेच अंमलबजावणीच्या धोक्यांचा सामना करावा लागतो.
GDPR अंतर्गत स्थानिक संग्रहणासाठी अनुपालन चेकलिस्ट:
- पहिल्या-पक्ष आणि तृतीय-पक्ष स्क्रिप्टद्वारे लिहिलेल्या सर्व स्थानिक संग्रहण कीजचे ऑडिट करा.
- प्रत्येक की वर्गीकृत करा: ती सेवा साठी अत्यावश्यक आहे का, किंवा ती विश्लेषण/जाहिरात साठी वापरली जाते?
- अनावश्यक संग्रहणासाठी, दस्तऐवज केलेल्या वापरकर्ता संमतीच्या मागे लेखन कार्य गेट करा.
- वापरकर्त्यांना संमती मागे घेण्याची स्पष्ट यंत्रणा प्रदान करा आणि संग्रहण मिटवणे ट्रिगर करा.
- डेटा नियंत्रकाच्या वैध हिताची किंवा संमती रेकॉर्डची दस्तऐवज करा.
Biscotti CMP सारख्या योग्यरित्या कॉन्फिगर केलेल्या संमती व्यवस्थापन प्लॅटफॉर्मने या संमती जीवनचक्राच्या बहुतेक भागांचे स्वयंचलन केले जाऊ शकते.
स्थानिक संग्रहण विविध वेबसाइट्सवर प्रवेश केला जाऊ शकतो का?
नाही. स्थानिक संग्रहण त्या मूळ (प्रोटोकॉल + डोमेन + पोर्ट संयोजन) वर कठोरपणे स्कोप केलेले आहे ज्याने ते तयार केले. https://siteA.com वर एक स्क्रिप्ट https://siteB.com द्वारे सेट केलेले स्थानिक संग्रहण डेटा वाचू शकत नाही. [4]
तथापि, या संरक्षणाची मर्यादा आहे. जर एकच जाहिरात किंवा विश्लेषण प्रदाता त्याच्या स्क्रिप्ट्सना siteA.com आणि siteB.com दोन्हीवर लोड करतो, तर प्रत्येक उदाहरण त्या संबंधित साइटच्या स्थानिक संग्रहणात स्वतंत्रपणे लेखन करते. प्रदाता नंतर सर्व्हर-साइडवर डेटा सहसंबंधित करतो, प्रभावीपणे समान मूळ धोरणाचे उल्लंघन न करता क्रॉस-साइट ट्रॅकिंग साध्य करतो.
गोपनीयता मोड आणि खाजगी ब्राउझिंग स्थानिक संग्रहणावर कसे परिणाम करतात?
खाजगी/गोपनीय ब्राउझिंग एक तात्पुरती संग्रहण विभाजन तयार करते जी खाजगी विंडो बंद झाल्यावर मिटवली जाते. गोपनीय सत्रादरम्यान लिहिलेल्या स्थानिक संग्रहणाचे मुख्य ब्राउझर प्रोफाइलवर टिकत नाही आणि नियमित ब्राउझिंग विंडोमध्ये प्रवेश केला जात नाही.
सत्र संग्रहण गोपनीय ब्राउझिंगमध्ये नियमित ब्राउझिंगप्रमाणेच वागते: टॅब बंद झाल्यावर ते मिटवले जाते.
महत्त्वाचे सावधगिरी:
- सक्रिय गोपनीय सत्रामध्ये, स्थानिक संग्रहण त्या सत्राच्या समान मूळ संदर्भात चालणाऱ्या सर्व स्क्रिप्टद्वारे वाचनयोग्य आहे.
- गोपनीय मोड वास्तविक वेळेत XSS-आधारित डेटा बाहेर काढण्यापासून प्रतिबंधित करत नाही.
- काही ब्राउझर स्थानिक संग्रहण डिव्हाइसवर समक्रमित करतात जर वापरकर्ता ब्राउझर समक्रमणात साइन इन असेल, एक वर्तन जे "स्थानिक" डेटा क्लाउड इन्फ्रास्ट्रक्चरवर हलवू शकते.
गोपनीयतेसाठी सत्र संग्रहण आणि स्थानिक संग्रहण कसे साफ करावे?
ब्राउझर संग्रहण साफ करणे सोपे आहे परंतु स्थानिक संग्रहणासाठी स्वयंचलितपणे ते करत नाहीत म्हणून ठरवलेले कार्य आवश्यक आहे.
ब्राउझर-स्तरीय साफसफाई:
- Chrome: सेटिंग्ज > गोपनीयता आणि सुरक्षा > ब्राउझिंग डेटा साफ करा > कॅश केलेले चित्रे आणि फायली + साइट डेटा
- Firefox: सेटिंग्ज > गोपनीयता आणि सुरक्षा > कुकीज आणि साइट डेटा > डेटा साफ करा
- Safari: सेटिंग्ज > गोपनीयता > वेबसाइट डेटा व्यवस्थापित करा
कार्यप्रणालीद्वारे साफसफाई (विकासकांसाठी):
localStorage.clear()मूळसाठी सर्व कीज काढते.sessionStorage.clear()वर्तमान टॅब सत्रासाठी सर्व कीज काढते.localStorage.removeItem('keyName')विशिष्ट की काढते.
ट्रॅकिंगबद्दल चिंतित अंतिम वापरकर्त्यांसाठी: ब्राउझर सेटिंग्जमध्ये "साइट डेटा" किंवा "कुकीज आणि संग्रहण" साफ करणे स्थानिक संग्रहण आणि सत्र संग्रहण सामग्री दोन्ही काढून टाकते. गोपनीयतेसाठी डिझाइन केलेले ब्राउझर विस्तार हे साइट किंवा सत्रानुसार स्वयंचलित करू शकतात.
वेब संग्रहणासह विकासकांनी केलेल्या सामान्य गोपनीयता चुकांमध्ये काय आहे?
सर्वात परिणामकारक चुकांमध्ये एक सामान्य मूळ आहे: क्लायंट-साइड संग्रहणाला सुरक्षित सर्व्हर-साइड डेटाबेस म्हणून विचार करणे.
- स्थानिक संग्रहणात JWTs संग्रहित करणे: स्थानिक संग्रहणात संग्रहित प्रमाणीकरण टोकन पृष्ठावरील कोणत्याही स्क्रिप्टसाठी उपलब्ध आहेत. एकच XSS असुरक्षा प्रत्येक वापरकर्त्याच्या टोकनला उघड करते. त्याऐवजी प्रमाणीकरण टोकनसाठी HttpOnly कुकीज वापरा.
- कोणतीही समाप्ती तत्त्वज्ञान नाही: स्थानिक संग्रहणात TTL नाही. डेटा समाप्ती तत्त्वज्ञान न बांधणारे विकासक उपकरणांवर अनिश्चित काळासाठी जुना, संवेदनशील डेटा ठेवतात.
- समान मूळ म्हणजे सुरक्षित आहे असे गृहित धरणे: समान मूळ धोरण बाह्य साइट्सला ब्लॉक करते, परंतु त्याच साइटवरून लोड केलेल्या दुष्ट स्क्रिप्ट्सपासून (XSS, तडजोड केलेले तृतीय-पक्ष लायब्ररी).
- तृतीय-पक्ष स्क्रिप्ट प्रवेशाकडे दुर्लक्ष करणे: स्थानिक संग्रहणातून काय वाचले जाते हे ऑडिट न करता विश्लेषण किंवा जाहिरात स्क्रिप्ट समाविष्ट करणे.
- ट्रॅकिंग संग्रहणासाठी कोणतीही संमती गेट नाही: वापरकर्ता संमती मिळवण्यापूर्वी स्थानिक संग्रहणात विश्लेषण ओळखकर्ते लेखन करणे, एक थेट GDPR उल्लंघन. [2]
- अतिरिक्त PII संग्रहित करणे: स्थानिक संग्रहणात "कामगिरीसाठी" संपूर्ण वापरकर्ता प्रोफाइल समाविष्ट करणारे API प्रतिसाद कॅश करणे, उघडकीस येण्याच्या पृष्ठभागाबद्दल विचार न करता.
स्थानिक संग्रहणापेक्षा IndexedDB अधिक गोपनीय आहे का?
IndexedDB स्थानिक संग्रहणापेक्षा अंतर्निहित अधिक गोपनीय नाही. दोन्ही समान मूळ धोरणाचे पालन करतात, दोन्ही पृष्ठावर चालणाऱ्या JavaScript साठी उपलब्ध आहेत, आणि दोन्ही XSS हल्ल्यांना असुरक्षित आहेत.
IndexedDB अधिक संग्रहण क्षमता प्रदान करते आणि संरचित डेटा आणि बायनरी ब्लॉबला समर्थन देते, ज्यामुळे ते जटिल ऑफलाइन अनुप्रयोगांसाठी योग्य बनते. परंतु गोपनीयता आणि सुरक्षा दृष्टिकोनातून, धोके तुलनात्मक आहेत. IndexedDB मध्ये संग्रहित डेटा देखील स्वयंचलितपणे एनक्रिप्ट केलेला नाही, आणि ते स्पष्टपणे मिटवले जात नाही तोपर्यंत अनिश्चित काळासाठी टिकतो.
IndexedDB आणि स्थानिक संग्रहण यामध्ये निवड डेटा जटिलता आणि प्रमाण आवश्यकतांद्वारे चालवली जावी, गोपनीयता गृहितकांद्वारे नाही. संवेदनशील वैयक्तिक डेटा साठी कोणतेही योग्य नाहीत, अनुप्रयोग-स्तरीय एनक्रिप्शन आणि कठोर प्रवेश नियंत्रणाशिवाय.
निष्कर्ष
सत्र संग्रहण आणि स्थानिक संग्रहण: वेब संग्रहण API च्या गोपनीयतेवरील परिणाम याबद्दल चर्चा ही फक्त एक तांत्रिक नोट नाही, ती वापरकर्त्यांच्या गोपनीयतेवर, नियामक अनुपालनावर, आणि अनुप्रयोग सुरक्षा वर थेट परिणाम करते. स्थानिक संग्रहणाची अनिश्चित टिकाऊपणा आणि क्रॉस-टॅब प्रवेश हे उच्च धोका असलेले संग्रहण यंत्रणा बनवते, तर सत्र संग्रहणाची टॅब बंद झाल्यावर स्वयंचलितपणे मिटवणे तात्पुरत्या स्थितीसाठी अधिक सुरक्षित पर्याय बनवते.
2026 मध्ये विकासक आणि वेबसाइट मालकांसाठी कार्यक्षम पुढील पायऱ्या:
- ब्राउझर DevTools (अनुप्रयोग टॅब) वापरून पहिल्या-पक्ष आणि तृतीय-पक्ष स्क्रिप्टमध्ये सर्व स्थानिक संग्रहण आणि सत्र संग्रहण वापराचे ऑडिट करा.
- तात्काळ क्लायंट-साइड संग्रहणातून कोणतीही प्रमाणीकरण टोकन, PII, किंवा संवेदनशील ओळखकर्ते काढा.
- स्थानिक संग्रहण-आधारित प्रमाणीकरण टोकन संग्रहण HttpOnly, सुरक्षित कुकीजने सर्व्हर-साइड व्यवस्थापित करा.
- दस्तऐवज केलेल्या वापरकर्ता संमतीच्या मागे अनावश्यक स्थानिक संग्रहण लेखन गेट करण्यासाठी संमती व्यवस्थापन कार्यप्रवाह कार्यान्वित करा, Biscotti CMP सारख्या प्लॅटफॉर्मचा वापर करून.
- कोणत्याही स्थानिक संग्रहण डेटा जो टिकवला पाहिजे त्यामध्ये समाप्ती तत्त्वज्ञान तयार करा, आणि लॉगआउटवर स्वच्छता लागू करा.
- तृतीय-पक्ष स्क्रिप्ट ऑडिट करा जेणेकरून कोणता बाह्य कोड आपल्या मूळच्या संग्रहणातून वाचू शकतो हे समजून घ्या.
- दोन्ही संग्रहण प्रकारांवर XSS प्रतिबंधित करण्यासाठी विकासक संघांना प्रशिक्षित करा.
वेब संग्रहण API शक्तिशाली साधने आहेत. गोपनीयता शिस्त न ठेवता वापरल्यास, ते जबाबदारीचे वेक्टर बनतात. ठरवलेल्या स्कोपिंग, संमती व्यवस्थापन, आणि सुरक्षा स्वच्छतेसह वापरल्यास, ते वापरकर्त्यांच्या विश्वासास धक्का न लावता त्यांच्या उद्देशानुसार कार्य करतात.
FAQ
प्रश्न: सत्र संग्रहण आणि स्थानिक संग्रहण यामध्ये मुख्य फरक काय आहे? स्थानिक संग्रहण अनिश्चित काळासाठी सत्रांमध्ये टिकते आणि समान मूळच्या सर्व टॅबमध्ये सामायिक केले जाते. सत्र संग्रहण फक्त वर्तमान टॅबच्या आयुष्यात डेटा संग्रहित करते आणि टॅब बंद झाल्यावर स्वयंचलितपणे मिटवले जाते.
प्रश्न: स्थानिक संग्रहणाचा वापर करून वापरकर्त्यांना कुकीशिवाय ट्रॅक केले जाऊ शकते का? होय. स्थानिक संग्रहणात संग्रहित एक अद्वितीय ओळखकर्ता कुकी हटवल्यानंतर टिकतो आणि एकाच साइटवर अनेक भेटींमध्ये वापरकर्त्यांना ट्रॅक करण्यासाठी वापरला जाऊ शकतो, एक टिकाऊ ट्रॅकिंग यंत्रणा म्हणून कार्य करतो.
प्रश्न: पासवर्ड संग्रहित करण्यासाठी सत्र संग्रहण सुरक्षित आहे का? नाही. सत्र संग्रहण एनक्रिप्ट केलेले नाही आणि पृष्ठावर चालणाऱ्या कोणत्याही JavaScript साठी उपलब्ध आहे, समाविष्ट केलेल्या दुष्ट स्क्रिप्टसह. पासवर्ड कोणत्याही क्लायंट-साइड संग्रहण यंत्रणेत संग्रहित केले जाऊ नयेत.
प्रश्न: GDPR स्थानिक संग्रहणावर लागू होते का? होय. GDPR अंतर्गत, स्थानिक संग्रहणात ट्रॅकिंग ओळखकर्ते किंवा वैयक्तिक डेटा संग्रहित करणे कायदेशीर आधाराशिवाय, सामान्यतः अनावश्यक उद्देशांसाठी स्पष्ट वापरकर्ता संमती आवश्यक आहे, हे अनुपालन उल्लंघन आहे.
प्रश्न: तृतीय-पक्ष स्क्रिप्ट माझा स्थानिक संग्रहण डेटा वाचू शकतात का?
होय, जर त्या स्क्रिप्ट्स समान मूळमध्ये लोड आणि कार्यान्वित केल्या जातात. <script> टॅगद्वारे समाविष्ट केलेले तृतीय-पक्ष विश्लेषण किंवा जाहिरात स्क्रिप्ट होस्ट पृष्ठाच्या मूळ संदर्भात चालतात आणि त्या मूळसाठी सर्व स्थानिक संग्रहण डेटा वाचू शकतात.
प्रश्न: कुकीज साफ केल्याने स्थानिक संग्रहण देखील साफ होते का? सर्व ब्राउझरमध्ये नाही. "कुकीज" साफ करणे एकट्याने सामान्यतः स्थानिक संग्रहण साफ करत नाही. वापरकर्त्यांना स्थानिक संग्रहण सामग्री काढून टाकण्यासाठी "साइट डेटा" किंवा "कुकीज आणि इतर साइट डेटा" स्पष्टपणे साफ करणे आवश्यक आहे.
प्रश्न: गोपनीयता मोड स्थानिक संग्रहण ट्रॅकिंगपासून सुरक्षित आहे का? गोपनीयता मोड स्थानिक संग्रहण डेटा खाजगी विंडो बंद झाल्यावर टिकत नाही, परंतु सक्रिय गोपनीय सत्रामध्ये, स्थानिक संग्रहण पृष्ठावर चालणाऱ्या सर्व स्क्रिप्टद्वारे वाचनयोग्य आहे.
प्रश्न: प्रमाणीकरण टोकनसाठी स्थानिक संग्रहणाऐवजी मला काय वापरावे? HttpOnly, सुरक्षित, SameSite कुकीज वापरा, ज्यांचे व्यवस्थापन सर्व्हर-साइड केले जाते. या कुकीजना JavaScript द्वारे प्रवेश नाही, त्यामुळे स्थानिक संग्रहणासह असलेल्या XSS-आधारित टोकन चोरण्याच्या धोका कमी होतो.
प्रश्न: IndexedDB स्थानिक संग्रहणापेक्षा अधिक सुरक्षित आहे का? नाही. IndexedDB स्थानिक संग्रहणासारख्या XSS असुरक्षा आणि समान मूळ धोरणाच्या अधीन आहे. हे अधिक क्षमता आणि डेटा संरचना समर्थन देते परंतु कोणतेही अतिरिक्त गोपनीयता किंवा सुरक्षा हमी नाही.
प्रश्न: स्थानिक संग्रहण आणि सत्र संग्रहण किती डेटा धारण करू शकतात? अधिकांश आधुनिक ब्राउझर प्रत्येक संग्रहण प्रकारासाठी प्रति मूळ सुमारे 5 ते 10 MB संग्रहण प्रदान करतात, जे कुकीजच्या 4 KB मर्यादेपेक्षा खूप अधिक आहे. [2]
संदर्भ
[1] सत्र संग्रहण - https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage?utm_source=openai
[2] स्थानिक संग्रहण म्हणजे काय सत्र संग्रहण - https://inspectwp.com/en/knowledge-base/what-is-localstorage-sessionstorage?utm_source=openai
[3] HTML5 वेब संग्रहण सुरक्षा धोके स्थानिक संग्रहण आणि सत्र संग्रहणाचे संरक्षण - https://www.dopethemes.com/html5-web-storage-security-risks-safeguarding-localstorage-and-sessionstorage/?utm_source=openai
[4] स्थानिक संग्रहण - https://javascript.info/localstorage?utm_source=openai
[5] स्थानिक संग्रहण सत्र संग्रहण - https://www.w3docs.com/learn-javascript/localstorage-sessionstorage?utm_source=openai
[6] कुकीज विरुद्ध स्थानिक संग्रहण विरुद्ध सत्र संग्रहण प्रत्येकाचा अर्थ काय आहे - https://www.interserver.net/tips/kb/cookies-vs-localstorage-vs-sessionstorage-what-each-one-exactly-means/?utm_source=openai