Câu trả lời nhanh: SessionStorage và localStorage đều là các API Lưu trữ Web dựa trên trình duyệt cho phép các trang web lưu trữ dữ liệu trên thiết bị của người dùng, nhưng chúng khác nhau một cách quan trọng về tính bền vững và phạm vi. localStorage giữ dữ liệu vô thời hạn qua các phiên và tab, trong khi sessionStorage xóa dữ liệu khi tab trình duyệt đóng. Từ góc độ quyền riêng tư, localStorage mang lại rủi ro cao hơn đáng kể vì dữ liệu tồn tại mà không có thời hạn, khiến nó trở thành mục tiêu hấp dẫn hơn cho việc theo dõi, nhận dạng dấu vân tay và sự giám sát quy định dưới các khung như GDPR.
Những điểm chính
- localStorage tồn tại vô thời hạn cho đến khi được xóa rõ ràng; sessionStorage bị xóa khi tab hoặc cửa sổ đóng.
- Cả hai loại lưu trữ đều dễ bị tấn công cross-site scripting (XSS) và không cung cấp mã hóa tích hợp.
- Dữ liệu trong localStorage và sessionStorage không được tự động truyền đến máy chủ, khác với cookie, nhưng cả hai đều có thể được đọc hoàn toàn bởi bất kỳ JavaScript nào chạy trên cùng một nguồn.
- Các tập lệnh bên thứ ba được tải trên một trang có thể truy cập dữ liệu localStorage nếu chúng chạy trong ngữ cảnh cùng nguồn.
- Theo GDPR, việc lưu trữ dữ liệu không cần thiết trong localStorage mà không có sự đồng ý của người dùng là một vi phạm tuân thủ, giống như việc thả cookie theo dõi.
- Dữ liệu nhạy cảm như mã thông báo xác thực, mật khẩu và thông tin nhận dạng cá nhân (PII) không bao giờ nên được lưu trữ trong bất kỳ cơ chế nào mà không có các lớp bảo mật bổ sung.
- Lướt web riêng tư/incognito giới hạn tính bền vững của localStorage nhưng không loại bỏ rủi ro sessionStorage trong một phiên.
- Các nhà phát triển nên ưu tiên sessionStorage cho trạng thái tạm thời, phiên phía máy chủ hoặc cookie HttpOnly cho xác thực, và một Nền tảng Quản lý Đồng ý như Biscotti CMP để quản lý sự đồng ý lưu trữ.
Sự khác biệt giữa SessionStorage và LocalStorage là gì?
SessionStorage và localStorage đều là một phần của API Lưu trữ Web HTML5, nhưng chúng phục vụ các mục đích khác nhau được xác định bởi tính bền vững và hành vi phạm vi tab.
localStorage lưu trữ các cặp khóa-giá trị mà không có ngày hết hạn. Dữ liệu tồn tại qua các lần khởi động trình duyệt, khởi động lại hệ thống và các khoảng thời gian không hoạt động vô thời hạn cho đến khi người dùng hoặc ứng dụng xóa nó một cách rõ ràng. Nó được chia sẻ giữa tất cả các tab và cửa sổ hoạt động dưới cùng một nguồn (giao thức + miền + cổng). [1][5]
sessionStorage chỉ lưu trữ dữ liệu trong suốt thời gian phiên trang. Khi người dùng đóng tab hoặc cửa sổ, dữ liệu sẽ biến mất. Quan trọng là, mỗi tab duy trì sessionStorage riêng biệt của nó, mở cùng một URL trong một tab thứ hai không chia sẻ dữ liệu sessionStorage của tab đầu tiên. [1]
| Tính năng | localStorage | sessionStorage |
|---|---|---|
| Tính bền vững | Vô thời hạn | Chỉ trong thời gian sống của tab/cửa sổ |
| Chia sẻ giữa các tab | Có (cùng nguồn) | Không (cách ly theo tab) |
| Tồn tại qua tải lại trang | Có | Có |
| Tồn tại qua đóng tab | Có | Không |
| Dung lượng lưu trữ | ~5-10 MB mỗi nguồn | ~5-10 MB mỗi nguồn |
| Truyền đến máy chủ | Không | Không |
| Bảo vệ HttpOnly | Không có | Không có |
Cả hai API đều tuân thủ chính sách cùng nguồn, vì vậy một trang tại https://example.com không thể đọc lưu trữ được thiết lập bởi https://otherdomain.com. [4]
localStorage có rủi ro quyền riêng tư so với sessionStorage không?
Có, localStorage mang lại rủi ro quyền riêng tư cao hơn đáng kể so với sessionStorage, chủ yếu là do tính bền vững vô thời hạn và khả năng truy cập giữa các tab.
Dữ liệu được ghi vào localStorage có thể tích lũy trong nhiều tháng hoặc nhiều năm mà người dùng không hề hay biết. Các nhà quảng cáo và nhà cung cấp phân tích đã sử dụng localStorage như một "siêu cookie", một định danh theo dõi tồn tại sau khi cookie bị xóa vì hầu hết người dùng không nghĩ đến việc xóa lưu trữ trình duyệt một cách thủ công. sessionStorage, ngược lại, tự hủy khi tab đóng, khiến nó trở thành một vector theo dõi ít hữu ích hơn.
Các yếu tố rủi ro quyền riêng tư chính độc đáo cho localStorage:
- Định danh theo dõi bền vững: Một ID duy nhất được lưu trữ trong localStorage có thể theo dõi một người dùng qua nhiều lần truy cập mà không cần cookie phía máy chủ.
- Rò rỉ dữ liệu giữa các tab: Bất kỳ tập lệnh nào chạy trong bất kỳ tab nào của cùng một nguồn đều có thể đọc tất cả dữ liệu localStorage.
- Phát sóng sự kiện lưu trữ: Các thay đổi đối với localStorage kích hoạt một sự kiện
storagetrong các tab mở khác từ cùng một nguồn, cho phép đồng bộ hóa dữ liệu giữa các tab mà người dùng không thể quan sát. [5] - Không có thời hạn tự động: Khác với cookie, hỗ trợ các thuộc tính
Max-AgevàExpires, localStorage không có cơ chế TTL.
Các trang web có thể theo dõi người dùng bằng localStorage và sessionStorage không?
Các trang web có thể và thực sự sử dụng localStorage cho việc theo dõi bền vững. sessionStorage ít hữu ích hơn cho việc theo dõi nhưng vẫn đặt ra rủi ro giám sát trong phiên.
Một dòng JavaScript đơn giản, localStorage.setItem('uid', 'abc123'), tạo ra một định danh bền vững tồn tại sau khi cookie bị xóa. Kỹ thuật này, đôi khi được gọi là "evercookie" hoặc tái sinh dựa trên lưu trữ, đã được ghi nhận trong nghiên cứu quyền riêng tư và là lý do mà các nhà quản lý ngày càng coi localStorage dưới cùng các quy tắc đồng ý như cookie.
sessionStorage có thể theo dõi hành vi trong một phiên duy nhất (luồng trang, đầu vào biểu mẫu, mẫu điều hướng), nhưng dữ liệu đó sẽ biến mất khi tab đóng, giới hạn tính hữu ích của nó cho việc lập hồ sơ lâu dài.
Dữ liệu ở lại trong SessionStorage so với LocalStorage bao lâu?
Dữ liệu localStorage sẽ tồn tại cho đến khi nó được xóa rõ ràng, bằng cách người dùng xóa lưu trữ trình duyệt, trang web gọi localStorage.removeItem() hoặc localStorage.clear(), hoặc trình duyệt thực thi các hạn chế lưu trữ. [2]
Dữ liệu sessionStorage sẽ bị xóa tự động khi tab hoặc cửa sổ tạo ra nó bị đóng. Nó tồn tại qua các lần tải lại trang trong cùng một tab nhưng không chuyển sang các tab mới, ngay cả khi người dùng sao chép tab trong một số trình duyệt. [1]
Ý nghĩa thực tiễn: Nếu một nhà phát triển lưu trữ một mã thông báo phiên trong localStorage thay vì sessionStorage, mã thông báo đó sẽ vẫn trên thiết bị sau khi người dùng đăng xuất, trừ khi ứng dụng xóa nó một cách rõ ràng. Đây là một sai lầm phổ biến và có hậu quả.
SessionStorage có riêng tư hơn localStorage không?
Đối với hầu hết các trường hợp sử dụng quyền riêng tư, có, sessionStorage là sự lựa chọn tôn trọng quyền riêng tư hơn. Việc tự động xóa khi tab đóng có nghĩa là dữ liệu không tồn tại lâu, giảm thiểu sự tiếp xúc từ việc chia sẻ thiết bị, thiết bị bị đánh cắp hoặc phân tích pháp y.
Tuy nhiên, sessionStorage không tự nó là "riêng tư". Trong một phiên hoạt động, nó cũng dễ bị tấn công XSS như localStorage. Bất kỳ tập lệnh nào được tiêm đều có thể gọi sessionStorage.getItem() và lấy dữ liệu trong thời gian thực. [3]
Chọn sessionStorage nếu: dữ liệu chỉ cần cho tương tác người dùng hiện tại (ví dụ: trạng thái biểu mẫu nhiều bước, mã thông báo điều hướng một lần).
Chọn localStorage nếu: dữ liệu thực sự cần tồn tại qua các phiên (ví dụ: sở thích giao diện người dùng của người dùng, cài đặt không nhạy cảm), và đảm bảo rằng nó không chứa bất kỳ thông tin nhận dạng cá nhân nào.
Dữ liệu cá nhân nào không bao giờ nên lưu trữ trong localStorage?
Các loại dữ liệu sau đây không bao giờ nên được lưu trữ trong localStorage (và nên được xử lý với sự cẩn trọng cực kỳ ngay cả trong sessionStorage): [3]
- Mã thông báo xác thực (JWT, mã thông báo OAuth, ID phiên)
- Mật khẩu hoặc băm mật khẩu
- Thông tin thẻ tín dụng hoặc thanh toán
- Số ID do chính phủ cấp hoặc số An sinh xã hội
- Họ tên đầy đủ kết hợp với địa chỉ email hoặc số điện thoại
- Hồ sơ y tế hoặc sức khỏe
- Bất kỳ dữ liệu nào được phân loại là "danh mục đặc biệt" theo GDPR (dữ liệu sinh trắc học, dữ liệu sức khỏe, ý kiến chính trị)
Dữ liệu được lưu trữ trong cả localStorage và sessionStorage đều không được mã hóa theo mặc định. Bất kỳ ai có quyền truy cập vật lý vào thiết bị, hoặc bất kỳ tập lệnh nào có khả năng thực thi trên trang, đều có thể đọc nó dưới dạng văn bản thuần túy. [3]
Các tập lệnh bên thứ ba có thể truy cập dữ liệu localStorage không?
Các tập lệnh bên thứ ba có thể truy cập dữ liệu localStorage nếu chúng được tải và thực thi trong cùng một nguồn với trang chủ. Đây là một rủi ro quan trọng và thường bị đánh giá thấp.
Khi một trang web nhúng một tập lệnh phân tích hoặc quảng cáo bên thứ ba thông qua thẻ <script>, tập lệnh đó chạy trong ngữ cảnh nguồn của trang chủ. Nó có thể đọc và ghi vào localStorage của trang đó một cách tự do. Chính sách cùng nguồn không bảo vệ chống lại các tập lệnh được bao gồm một cách cố ý hoặc vô tình trên trang. [4]
Điều này có nghĩa là gì trong thực tiễn: Nếu một trang lưu trữ một định danh người dùng trong localStorage và cũng tải một tập lệnh quảng cáo bên thứ ba, tập lệnh quảng cáo đó có thể đọc định danh và liên kết nó với dữ liệu hành vi giữa các trang, mà không có sự biết đến hoặc đồng ý của người dùng.
Đây là một lý do tại sao các Nền tảng Quản lý Đồng ý lại quan trọng. Biscotti CMP cho phép các trang web quản lý và ghi lại sự đồng ý của người dùng cho các hoạt động lưu trữ, bao gồm theo dõi dựa trên localStorage, giúp các trang đáp ứng nghĩa vụ của họ theo GDPR và các khung tương tự.
Các tác động của GDPR khi sử dụng localStorage là gì?
Theo GDPR, bất kỳ việc lưu trữ dữ liệu cá nhân hoặc định danh theo dõi nào, bất kể cơ chế kỹ thuật, đều yêu cầu một cơ sở hợp pháp. Đối với việc theo dõi không cần thiết thông qua localStorage, cơ sở đó hầu như luôn là sự đồng ý rõ ràng của người dùng. [2]
Hội đồng Bảo vệ Dữ liệu Châu Âu đã xác nhận rằng localStorage được sử dụng cho phân tích, quảng cáo hoặc lập hồ sơ người dùng thuộc cùng các yêu cầu đồng ý như cookie. Các trang web thả các định danh theo dõi vào localStorage mà không có sự đồng ý trước sẽ phải đối mặt với cùng mức độ phơi bày thực thi như những trang sử dụng cookie không được đồng ý.
Danh sách kiểm tra tuân thủ cho localStorage theo GDPR:
- Kiểm tra tất cả các khóa localStorage được ghi bởi các tập lệnh bên thứ nhất và bên thứ ba.
- Phân loại từng khóa: nó có thực sự cần thiết cho dịch vụ không, hay nó được sử dụng cho phân tích/quảng cáo?
- Đối với lưu trữ không cần thiết, yêu cầu hoạt động ghi phải được thực hiện sau khi có sự đồng ý của người dùng đã được ghi lại.
- Cung cấp cho người dùng một cơ chế rõ ràng để rút lại sự đồng ý và kích hoạt việc xóa lưu trữ.
- Ghi lại lợi ích hợp pháp của người kiểm soát dữ liệu hoặc hồ sơ sự đồng ý.
Một Nền tảng Quản lý Đồng ý được cấu hình đúng cách như Biscotti CMP có thể tự động hóa nhiều khía cạnh của vòng đời đồng ý này.
localStorage có thể được truy cập qua các trang web khác nhau không?
Không. localStorage được giới hạn nghiêm ngặt trong nguồn (giao thức + miền + cổng) mà nó được tạo ra. Một tập lệnh trên https://siteA.com không thể đọc dữ liệu localStorage được thiết lập bởi https://siteB.com. [4]
Tuy nhiên, sự bảo vệ này có giới hạn. Nếu một nhà cung cấp quảng cáo hoặc phân tích duy nhất tải các tập lệnh của mình trên cả siteA.com và siteB.com, mỗi phiên bản sẽ ghi vào localStorage của trang tương ứng một cách độc lập. Nhà cung cấp sau đó sẽ liên kết dữ liệu ở phía máy chủ, đạt được theo dõi giữa các trang mà không vi phạm chính sách cùng nguồn.
Chế độ ẩn danh và duyệt web riêng tư ảnh hưởng đến localStorage như thế nào?
Duyệt web riêng tư/ẩn danh tạo ra một phân vùng lưu trữ tạm thời sẽ bị xóa khi cửa sổ riêng tư đóng. localStorage được ghi trong một phiên ẩn danh sẽ không tồn tại trong hồ sơ trình duyệt chính và không thể truy cập từ các cửa sổ duyệt web thông thường.
sessionStorage hoạt động giống như trong duyệt web thông thường: nó sẽ bị xóa khi tab đóng.
Các lưu ý quan trọng:
- Trong một phiên ẩn danh đang hoạt động, localStorage vẫn có thể được đọc bởi tất cả các tập lệnh chạy trong ngữ cảnh cùng nguồn của phiên đó.
- Chế độ ẩn danh không ngăn chặn việc lấy dữ liệu dựa trên XSS theo thời gian thực.
- Một số trình duyệt đồng bộ hóa localStorage giữa các thiết bị nếu người dùng đã đăng nhập vào đồng bộ trình duyệt, một hành vi có thể di chuyển dữ liệu "cục bộ" vào hạ tầng đám mây.
Làm thế nào để tôi xóa SessionStorage và localStorage để bảo vệ quyền riêng tư?
Việc xóa lưu trữ trình duyệt là đơn giản nhưng yêu cầu hành động có chủ đích vì các trình duyệt không tự động thực hiện điều này cho localStorage.
Xóa ở cấp trình duyệt:
- Chrome: Cài đặt > Quyền riêng tư và Bảo mật > Xóa dữ liệu duyệt web > Hình ảnh và tệp đã lưu vào bộ nhớ đệm + Dữ liệu trang
- Firefox: Cài đặt > Quyền riêng tư & Bảo mật > Cookie và Dữ liệu trang > Xóa Dữ liệu
- Safari: Cài đặt > Quyền riêng tư > Quản lý Dữ liệu Trang web
Xóa theo chương trình (dành cho các nhà phát triển):
localStorage.clear()xóa tất cả các khóa cho nguồn.sessionStorage.clear()xóa tất cả các khóa cho phiên tab hiện tại.localStorage.removeItem('keyName')xóa một khóa cụ thể.
Đối với người dùng cuối lo ngại về việc theo dõi: xóa "dữ liệu trang" hoặc "cookie và lưu trữ" trong cài đặt trình duyệt sẽ xóa cả nội dung localStorage và sessionStorage cho tất cả các trang. Các tiện ích mở rộng trình duyệt được thiết kế cho quyền riêng tư có thể tự động hóa điều này theo từng trang hoặc từng phiên.
Những sai lầm phổ biến về quyền riêng tư mà các nhà phát triển mắc phải với Lưu trữ Web là gì?
Những sai lầm nghiêm trọng nhất đều có một nguồn gốc chung: coi lưu trữ phía khách như thể nó là một cơ sở dữ liệu an toàn phía máy chủ.
- Lưu trữ JWT trong localStorage: Các mã thông báo xác thực được lưu trữ trong localStorage có thể được truy cập bởi bất kỳ tập lệnh nào trên trang. Một lỗ hổng XSS đơn lẻ sẽ phơi bày mã thông báo của mọi người dùng. Sử dụng cookie HttpOnly cho các mã thông báo xác thực thay vào đó.
- Không có logic hết hạn: localStorage không có TTL. Các nhà phát triển lưu trữ dữ liệu mà không xây dựng logic hết hạn sẽ để lại dữ liệu nhạy cảm, cũ trên thiết bị vô thời hạn.
- Giả định cùng nguồn có nghĩa là an toàn: Chính sách cùng nguồn chặn các trang bên ngoài, không phải các tập lệnh độc hại được tải từ bên trong cùng một trang (XSS, thư viện bên thứ ba bị xâm phạm).
- Bỏ qua quyền truy cập của tập lệnh bên thứ ba: Nhúng các tập lệnh phân tích hoặc quảng cáo mà không kiểm tra những gì chúng đọc từ localStorage.
- Không có cổng đồng ý cho lưu trữ theo dõi: Ghi các định danh phân tích vào localStorage trước khi có được sự đồng ý của người dùng, một vi phạm trực tiếp GDPR. [2]
- Lưu trữ PII dư thừa: Lưu trữ các phản hồi API bao gồm hồ sơ người dùng đầy đủ trong localStorage "để cải thiện hiệu suất" mà không xem xét bề mặt phơi bày.
IndexedDB có riêng tư hơn localStorage không?
IndexedDB không tự nó riêng tư hơn localStorage. Cả hai đều bị chi phối bởi chính sách cùng nguồn, cả hai đều có thể truy cập bởi JavaScript chạy trên trang, và cả hai đều dễ bị tấn công XSS.
IndexedDB cung cấp dung lượng lưu trữ lớn hơn và hỗ trợ dữ liệu có cấu trúc và blob nhị phân, khiến nó phù hợp cho các ứng dụng ngoại tuyến phức tạp. Nhưng từ góc độ quyền riêng tư và bảo mật, các rủi ro là tương đương. Dữ liệu được lưu trữ trong IndexedDB cũng không được mã hóa theo mặc định và tồn tại vô thời hạn trừ khi bị xóa rõ ràng.
Sự lựa chọn giữa IndexedDB và localStorage nên được thúc đẩy bởi độ phức tạp và yêu cầu về khối lượng dữ liệu, không phải giả định về quyền riêng tư. Cả hai đều không phù hợp cho dữ liệu cá nhân nhạy cảm mà không có mã hóa ở lớp ứng dụng và kiểm soát truy cập nghiêm ngặt.
Kết luận
Cuộc tranh luận về SessionStorage so với LocalStorage: Ảnh hưởng đến quyền riêng tư của các API lưu trữ web không chỉ là một ghi chú kỹ thuật, nó có những hậu quả trực tiếp đối với quyền riêng tư của người dùng, tuân thủ quy định và bảo mật ứng dụng. Tính bền vững vô thời hạn của localStorage và khả năng truy cập giữa các tab khiến nó trở thành một cơ chế lưu trữ có rủi ro cao khi bị lạm dụng, trong khi việc tự động xóa của sessionStorage khi tab đóng khiến nó trở thành sự lựa chọn dễ bảo vệ hơn cho trạng thái tạm thời.
Các bước hành động có thể thực hiện cho các nhà phát triển và chủ sở hữu trang web vào năm 2026:
- Kiểm tra tất cả việc sử dụng localStorage và sessionStorage trên các tập lệnh bên thứ nhất và bên thứ ba bằng cách sử dụng DevTools của trình duyệt (tab Ứng dụng).
- Ngay lập tức xóa bất kỳ mã thông báo xác thực, PII hoặc định danh nhạy cảm nào khỏi lưu trữ phía khách.
- Thay thế việc lưu trữ mã thông báo xác thực dựa trên localStorage bằng cookie HttpOnly, Secure được quản lý ở phía máy chủ.
- Triển khai một quy trình quản lý đồng ý, sử dụng một nền tảng như Biscotti CMP, để yêu cầu các ghi chép không cần thiết vào localStorage phải có sự đồng ý của người dùng đã được ghi lại.
- Xây dựng logic hết hạn vào bất kỳ dữ liệu localStorage nào cần tồn tại, và thực thi việc dọn dẹp khi đăng xuất.
- Tiến hành kiểm tra tập lệnh bên thứ ba để hiểu những mã bên ngoài nào có thể đọc từ lưu trữ của nguồn bạn.
- Đào tạo các nhóm phát triển về phòng ngừa XSS như là vector tấn công chính chống lại cả hai loại lưu trữ.
Các API lưu trữ web là những công cụ mạnh mẽ. Nếu được sử dụng mà không có kỷ luật về quyền riêng tư, chúng trở thành các vector trách nhiệm. Nếu được sử dụng với phạm vi có chủ đích, quản lý đồng ý và vệ sinh bảo mật, chúng phục vụ mục đích của mình mà không làm tổn hại đến những người dùng tin tưởng ứng dụng của bạn.
Câu hỏi thường gặp
Q: Sự khác biệt chính giữa sessionStorage và localStorage là gì? localStorage tồn tại dữ liệu vô thời hạn qua các phiên và được chia sẻ giữa tất cả các tab của cùng một nguồn. sessionStorage chỉ lưu trữ dữ liệu trong suốt thời gian sống của tab hiện tại và sẽ bị xóa tự động khi tab đóng.
Q: localStorage có thể được sử dụng để theo dõi người dùng mà không cần cookie không? Có. Một định danh duy nhất được lưu trữ trong localStorage tồn tại sau khi cookie bị xóa và có thể được sử dụng để theo dõi người dùng qua nhiều lần truy cập vào cùng một trang, hoạt động như một cơ chế theo dõi bền vững.
Q: sessionStorage có an toàn để lưu trữ mật khẩu không? Không. sessionStorage không được mã hóa và có thể được truy cập bởi bất kỳ JavaScript nào chạy trên trang, bao gồm cả các tập lệnh độc hại được tiêm. Mật khẩu không bao giờ nên được lưu trữ trong bất kỳ cơ chế lưu trữ phía khách nào.
Q: GDPR có áp dụng cho localStorage không? Có. Theo GDPR, việc lưu trữ các định danh theo dõi hoặc dữ liệu cá nhân trong localStorage mà không có cơ sở hợp pháp, thường là sự đồng ý rõ ràng của người dùng cho các mục đích không cần thiết, là một vi phạm tuân thủ tương đương với việc sử dụng cookie không được đồng ý.
Q: Các tập lệnh bên thứ ba có thể đọc dữ liệu localStorage của tôi không?
Có, nếu các tập lệnh đó được tải và thực thi trong cùng một nguồn. Các tập lệnh phân tích hoặc quảng cáo bên thứ ba được nhúng thông qua các thẻ <script> chạy trong ngữ cảnh nguồn của trang chủ và có thể đọc tất cả dữ liệu localStorage cho nguồn đó.
Q: Xóa cookie có xóa luôn localStorage không? Không phải lúc nào cũng vậy. Trong hầu hết các trình duyệt, việc xóa "cookie" một mình không xóa localStorage. Người dùng phải cụ thể xóa "dữ liệu trang" hoặc "cookie và dữ liệu trang khác" để loại bỏ nội dung localStorage.
Q: Chế độ ẩn danh có an toàn khỏi việc theo dõi localStorage không? Chế độ ẩn danh ngăn dữ liệu localStorage tồn tại sau khi cửa sổ riêng tư đóng, nhưng trong một phiên ẩn danh đang hoạt động, localStorage vẫn có thể được đọc bởi tất cả các tập lệnh trên trang.
Q: Tôi nên sử dụng gì thay vì localStorage cho các mã thông báo xác thực? Sử dụng cookie HttpOnly, Secure, SameSite được quản lý ở phía máy chủ. Những cookie này không thể truy cập bởi JavaScript, loại bỏ rủi ro đánh cắp mã thông báo dựa trên XSS mà localStorage mang lại.
Q: IndexedDB có an toàn hơn localStorage không? Không. IndexedDB cũng chịu tác động của các lỗ hổng XSS và chính sách cùng nguồn như localStorage. Nó cung cấp dung lượng lớn hơn và hỗ trợ cấu trúc dữ liệu nhưng không có thêm bất kỳ đảm bảo quyền riêng tư hoặc bảo mật nào.
Q: localStorage và sessionStorage có thể chứa bao nhiêu dữ liệu? Hầu hết các trình duyệt hiện đại cấp khoảng 5 đến 10 MB dung lượng lưu trữ cho mỗi nguồn cho mỗi loại lưu trữ, nhiều hơn đáng kể so với giới hạn 4 KB điển hình của cookie. [2]
Tài liệu tham khảo
[1] Sessionstorage - https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage?utm_source=openai
[2] What Is Localstorage Sessionstorage - https://inspectwp.com/en/knowledge-base/what-is-localstorage-sessionstorage?utm_source=openai
[3] Html5 Web Storage Security Risks Safeguarding Localstorage And Sessionstorage - https://www.dopethemes.com/html5-web-storage-security-risks-safeguarding-localstorage-and-sessionstorage/?utm_source=openai
[4] Localstorage - https://javascript.info/localstorage?utm_source=openai
[5] Localstorage Sessionstorage - https://www.w3docs.com/learn-javascript/localstorage-sessionstorage?utm_source=openai
[6] Cookies Vs Localstorage Vs Sessionstorage What Each One Exactly Means - https://www.interserver.net/tips/kb/cookies-vs-localstorage-vs-sessionstorage-what-each-one-exactly-means/?utm_source=openai