和localStorage的主要区别在于生命周期和作用域：sessionStorage数据持久保存，除非手动清除，且同源的所有标签页共享；localStorage仅在当前标签页会话期间有效，关闭即销毁，各标签页间相互隔离。应根据数据是否需长期保留及共享范围选择使用——长期非敏感配置用sessionStorage，临时会话数据用localStorage。安全方面，二者均易受XSS攻击导致明文数据泄露，故绝不可存储敏感信息如令牌或密码，推荐使用sessionStorageCookie替代，并始终在服务端验证客户端数据。HttpOnly
Web存储中的
localStorage和
sessionStorage是浏览器提供的两种客户端数据存储机制。它们的核心作用是让Web应用能在用户浏览器端存储键值对数据，从而实现一些本地化功能或提升用户体验。简单来说，
localStorage就像一个永不失效的便签本，只要你不主动擦掉，它就一直在那里；而
sessionStorage则更像一个临时的、每次会话（浏览器标签页关闭即消失）都会清空的草稿纸。在与服务端协作时，它们本身不直接参与数据传输，但其存储的数据内容和方式，却与Web应用整体的安全性息息相关，尤其需要警惕跨站脚本（XSS）攻击导致的敏感信息泄露风险。
解决方案
localStorage和
sessionStorage都是基于同源策略的键值对存储机制，它们的数据都以字符串形式保存。理解它们的运作方式和区别，是正确使用并确保安全的前提。
localStorage提供的是持久化存储。这意味着一旦数据被写入，除非用户手动清除浏览器数据，或者Web应用通过JavaScript代码明确删除，否则这些数据会一直保留在用户的设备上，即使浏览器关闭再打开也依然存在。这使得它非常适合存储那些需要长期保留的用户偏好设置，比如主题选择、语言设置，或者是一些不敏感的、用于提升加载速度的静态数据缓存。
而
sessionStorage则提供了一种会话级别的存储。它的生命周期与当前浏览器标签页（或窗口）的生命周期绑定。当用户关闭了该标签页或窗口，存储在
sessionStorage中的所有数据都会被自动清除。这意味着，即使是同一个网站，在不同的标签页中打开，它们各自的
sessionStorage也是独立的，互不干扰。这让
sessionStorage成为存储临时性、单次会话有效的数据的理想选择，例如用户在多步表单填写过程中的中间数据，或者某个特定页面会话的状态信息。
这两种存储机制都提供了简单的API：
setItem(key, value)用于存储数据，
getItem(key)用于获取数据，
removeItem(key)用于删除数据，以及
clear()用于清空所有数据。它们的操作都是同步的，这意味着在数据读写过程中，浏览器的主线程会被阻塞，对于大量数据的操作可能会影响页面性能，不过对于大多数场景而言，其存储容量（通常在5MB到10MB之间）和操作速度是足够用的。
localStorage
localStorage在我看来，区分
localStorage和
sessionStorage最核心的，就是它们的生命周期和作用域。
localStorage的生命周期是持久的。它不随浏览器关闭而消失，除非被显式删除。它的作用域是同源的，即在同一个域名下，所有标签页和窗口都可以访问和共享这份数据。所以，当你的应用需要记住用户的一些非敏感、长期有效的设置时，比如用户界面的主题偏好、上次访问的某个不涉及隐私的页面状态，或者是一些静态资源的版本号来优化缓存，
localStorage就是那个最合适的选择。想象一下，你希望用户下次打开网站时，依然保持上次选择的深色模式，那这数据就该放在
localStorage里。
而
sessionStorage的生命周期是会话级的。它只在当前标签页或窗口的生命周期内有效，一旦关闭，数据就烟消云散。更重要的是，它的作用域是单个标签页/窗口的，即使是同一个网站，在不同标签页里打开，它们的
sessionStorage也是独立的，互不影响。这在很多场景下非常有用，比如你有一个多步骤的表单，用户每填写一步，数据就临时保存到
sessionStorage，这样即使不小心刷新了页面，数据还在；但一旦用户完成提交或关闭标签页，这些临时数据就自动清理了，不会留下痕迹。再比如，你可能需要在一个会话中存储一些临时的导航状态或者用户操作的痕迹，
sessionStorage就显得非常灵活和安全，因为它不会“污染”其他会话，也不会长期驻留。
选择哪一个，其实就是看你的数据需要“活”多久，以及在多大的范围内共享。如果你希望数据能跨越多次访问，且在所有同源页面共享，那就选
localStorage；如果你只需要数据在当前标签页的单次会话中有效，并且不希望它影响到其他标签页，那
sessionStorage是你的不二之选。
在Web存储中存储敏感数据有哪些潜在的安全风险？
坦白说，在
localStorage或
sessionStorage中存储任何形式的敏感数据，都是一个高风险行为。这几乎是Web安全领域的一个共识。为什么呢？
首先，最大的威胁来自跨站脚本（XSS）攻击。如果你的Web应用存在XSS漏洞，攻击者可以通过注入恶意JavaScript代码，轻而易举地访问到
localStorage和
sessionStorage中的所有数据。一旦数据被恶意脚本获取，它就可以被发送到攻击者控制的服务器，从而导致用户凭证、个人身份信息（PII）或其他敏感信息的泄露。这就像你把家里钥匙放在一个玻璃盒子里，虽然盒子有锁，但如果有人能打破玻璃，锁就形同虚设了。Web存储就是那个玻璃盒子，XSS就是打破玻璃的锤子。
其次，
localStorage和
sessionStorage中的数据是明文存储的。这意味着它们不会被浏览器自动加密。任何有权访问用户本地文件系统的人（例如，通过恶意软件或物理访问设备），都可能直接读取这些存储文件，从而获取敏感信息。虽然这通常需要更高级的攻击手段，但对于高度敏感的数据，这种风险是不可忽视的。
ai_manual/000/000/000/175680352343650.png" alt="什么是Web存储的localStoragesessionStorage
再者，
localStorage的数据是持久的。这意味着一旦被存储，它会一直存在，直到被手动清除。如果一个用户的设备被盗或被共享，并且浏览器中存储了敏感数据，那么这些数据就会长时间暴露在风险之下。
sessionStorage虽然生命周期较短，但在会话期间，同样面临XSS攻击的威胁。
所以，无论你觉得数据有多么“不敏感”，只要它能被用于识别用户、进行认证，或者涉及任何隐私，就不应该直接存储在
localStorage或
sessionStorage中。
如何安全地使用localStoragesessionStorage
localStoragesessionStorage要安全地使用
localStorage和
sessionStorage，核心原则就是：不要存放敏感数据。这听起来简单，但实践中却常常被忽视。
-
绝不存储认证凭证和敏感令牌： 比如用户的密码、OAuth access tokens（尤其是长寿命的）、刷新令牌（refresh tokens）、会话ID等。这些东西一旦泄露，攻击者就能冒充用户。对于认证令牌，更推荐使用
HttpOnly属性的Cookie。
HttpOnly的Cookie无法通过JavaScript访问，大大降低了XSS攻击的风险。虽然它们仍然可以通过HTTP请求发送到服务器，但在客户端脚本层面，它们是受保护的。
-
防止XSS攻击是首要任务： 既然XSS是Web存储安全的最大威胁，那么从根本上杜绝XSS漏洞就至关重要。这意味着：
-
仅存储非敏感、可公开或易于重建的数据： 比如用户界面的偏好设置（主题、语言）、非关键的UI状态、公开的配置信息、或是一些可以从服务端轻易重新获取或重建的缓存数据。如果数据丢失不会造成任何安全或隐私问题，那它就是可以考虑存储的。
-
对存储的数据进行最小化处理： 即使是非敏感数据，也只存储你真正需要的那部分。数据量越小，潜在的暴露面也越小。
-
服务端数据应始终作为权威来源： 客户端存储的数据永远不应该被服务端盲目信任。任何来自客户端的数据，无论其来源是
localStorage还是表单提交，都必须在服务端进行严格的验证和授权检查，以防止篡改和滥用。Web存储只是提供客户端便利，而不是替代服务端的数据管理和安全逻辑。
-
考虑替代方案： 对于需要存储大量结构化数据或更复杂的数据管理需求，可以考虑使用IndexedDB。它提供了更强大的API和更大的存储容量，并且可以更好地控制数据的访问权限（虽然仍然受XSS影响）。对于需要严格安全控制的会话数据，
HttpOnlyCookie通常是更好的选择。
总之，
localStorage和
sessionStorage是Web开发中的利器，但它们并非万能，更不是保险箱。理解它们的局限性，并始终将“安全第一”的原则放在心上，才能真正发挥它们的作用，同时避免不必要的安全风险。
以上就是什么是Web存储的localStorage