虽然更详细地说，浏览WEB的历史记录也可以看作是本地存储的一种形式。 至此，HTML5本地存储方式已得到广泛支持。 支持的浏览器包括：IE8+、FF3.5+、Safari4+、Chrome4+、Opera10.5+，手机平台包括iPhone2+、Android2+。可在线查看最新的HTML5本地存储规范文档
HTML5本地存储的前身是Cookie。 HTML5本地存储使用localStorage对象在本地保存WEB数据。 相比之下，HTML5本地存储中每个域的默认存储大小为5M，比cookie的4K大得多。 而存储和读取数据的代码也极其简单：
所以现在我们可以简单的感觉到HTML5存储已经可以替代cookie存储了。 而这些新的存储形式在实际应用中带来了新的安全风险。 带着这个疑问，我们进行下面的讨论。
(1)是否可以替代Cookie
浏览器使用cookie进行认证已经很多年了，那么现在localStorage有这么大的存储空间，是不是可以直接把认证数据移植过来呢？ 从目前来看，使用localStorage存储认证数据还不成熟。 我们知道XSS漏洞一般可以用来获取cookie，然后利用这个cookie进行身份验证和登录。后来为了避免通过XSS获取Cookie数据，浏览器支持使用HTTPONLY来保护Cookie不被其他人获取XSS 攻击。 并且localStorage存储没有任何防XSS攻击机制。 一旦出现XSS漏洞，localStorage中存储的数据就可以轻易获取。
如果网站存在XSS漏洞，攻击者可以注入以下代码来获取使用localStorage本地存储的所有信息。
攻击者还可以简单地使用 localStorage.removeItem(key) 和 localStorage.clear() 来清除存储的数据。
(2)不存储敏感信息
由(1)可知html5 本地存储，localStorage中存储的数据很容易被远程攻击的XSS攻击获取，因此不宜在localStorage中存储认证信息或敏感信息。 从本地攻击的角度来看，从localStorage本身的存储形式和存储时限来看，不适合存储敏感信息。
五大浏览器都已经支持localStorage形式的存储，其中Chrome、Opera、Safari都有查看本地存储的功能模块。 并且不同的浏览器对于localStorage的存储方式也略有不同。 以下是五种主要的浏览器localStorage存储方式：
从前面的描述可以看出，不仅Opera浏览器使用BASE64加密（BASE64也可以很容易破译）html5 本地存储，其他浏览器都使用明文来存储数据。
另一方面，在数据存储时效性方面，localStorage并没有像cookie那样设置数据的生存期。 只要用户不主动删除，localStorage中存储的数据就会永远存在。
基于以上存储方式和存储时效性的分析，建议不要使用localStorage存储敏感信息，即使信息是加密的。
(3)严格过滤输入输出
对于本地存储来说，为了方便重新加载数据，往往将数据存储在本地。 再次加载时，直接从本地读取数据并显示在网页上。 某些情况下，在localStorage中写入或读取数据时，如果没有对数据进行严格的输入输出过滤，这些数据很容易被解析为HTML代码，从而形成XSS攻击。
Twitter 存在 localStorageXSS 漏洞。 触发该漏洞的条件是，在 Twitter 个人主页上执行以下存储代码后，每次打开个人主页都会弹出 /xss/ 框。
从这段代码可以看出，Twitter会使用localStorage在本地存储一些个人数据。 每次加载个人主页时，都会从本地存储中检索数据。 后来，由于 Twitter 忽略了对清除数据的严格过滤，因此会导致存储的代码将作为 HTML 代码执行，从而产生跨站攻击。
有关TwitterlocalStorageXSS漏洞的详细信息可以参见：wooyun-2010-03075。 事实上，利用Twitter的漏洞是非常困难的，但它再次告诉我们，所有的输入和输出都是有害的，应对数据进行严格的输入和输出过滤。
(4)容易受到跨目录攻击
localStroage存储方法不像Cookie存储那样指定域中的路径，localStroage存储方法中没有域路径的概念。 也就是说，如果某个域下的任意路径存在XSS漏洞，只要知道存储名称就可以获取整个域中存储的数据。
假设以下两个链接使用localStorage来存储数据：
用户 xisigr 和 xhack 各自的博客链接似乎属于同一域，但具有不同的路径，一个用于 xisigr，另一个用于 xhack。 假设xisigr用户发现自己的路径存在存储XSS漏洞，那么他可以在自己的博客中添加数据获取代码，其中核心代码为localStorage.getItem(“name”)。 xhack用户不需要登录博客，只要访问，就会获取本地存储数据。
(5)容易受到DNS误导攻击
Google在使用HTML5本地存储之前，使用的是GoogleGears方式进行本地存储。 当时，GoogleGears 遭受了 DNS 误导性攻击。 GoogleGears 支持离线存储。 它可以以SQLite数据库的形式存储Gmail、WordPress等网站数据，然后用户可以离线读取或删除所存储的网站数据。 如果攻击者发起 DNS 误导攻击，则可以注入本地数据库、获取数据或留下永久侧门。 这将对用户造成持久的伤害。 GoogleGears 遇到的同类 DNS 误导攻击对 HTML5 本地存储也有效。
（六）恶意代码滋生的土壤
在第六点中给出副标题“恶意代码的温床”有点夸大了功效。 虽然这里我想说的是HTML5本地存储无论从空间还是时间上都将是未来的存储趋势。 预计“恶意代码”自然会南下，迁往这个温床。
那么，HTML5本地存储的空间和时间是多少呢？ 这里的空间指的是存储空间。 与 Cookie4K 的小空间相比，HTML5 的 localStroage 方法可以让浏览器默认存储 5M 的空间，可以说是巨大的，而 Safari 浏览器最大可以支持 500M，这让 HTML5 的存储更加帅气、暴露。 从时间上来看，随着HTML5技术逐渐成熟，不仅各大浏览器厂商争先恐后地在自己的产品中支持HTML5，一些主要应用软件厂商也对其抱有良好的信任。 例如，2011年11月，Adobe宣布将放弃手机上的FLASH，转而采用HTML5。 随着时间的推移，HTML5的发展速度会越来越快，也将推动越来越多使用HTML5本地存储的应用程序。
从理论上分析了“恶意代码滋生地”的可能性。 实际技术可行性也很简单。 以下是本地留侧门的核心代码：
