我想通过将所有cookie移到本地存储中来减少其加载时间，因为它们似乎具有相同的功能。除了明显的兼容性问题以外，使用本地存储替换cookie功能是否有任何利弊（特别是性能方面的优势）？

#1楼

好吧，本地存储速度很大程度上取决于客户端使用的浏览器以及操作系统。 Mac上的Chrome或Safari可能比PC上的Firefox快得多，尤其是使用较新的API时。与往常一样，测试是您的朋友（我找不到任何基准）。

我真的没有看到Cookie与本地存储的巨大差异。另外，您应该更加担心兼容性问题：并不是所有的浏览器都已经开始支持新的HTML5 API，因此cookie是提高速度和兼容性的最佳选择。

#2楼

Cookies和本地存储有不同的用途。 Cookies主要用于读取服务器端 ，本地存储只能由客户端读取。因此，问题是，在您的应用程序中，谁需要此数据-客户端还是服务器？

如果它是您的客户端（您的JavaScript），则一定要切换。通过在每个HTTP标头中发送所有数据来浪费带宽。

如果是您的服务器，则本地存储不是那么有用，因为您必须以某种方式（使用Ajax或隐藏的表单字段或其他方式）转发数据。如果服务器仅需要每个请求的全部数据的一小部分，则可以这样做。

无论哪种方式，您都希望将会话cookie保留为cookie。

根据技术差异以及我的理解：

除了作为一种古老的数据保存方式之外，Cookie还为您提供了4096个字节的限制（实际上为4095 个字节），即每个cookie的限制。 每个域的本地存储最大为5MB - SO Question也提到了它
localStorage是Storage接口的实现。它存储没有到期日期的数据，并且仅通过JavaScript或清除浏览器缓存/本地存储的数据来清除-与cookie到期不同。

#3楼

使用localStorage ，Web应用程序可以在用户的浏览器中本地存储数据。在HTML5之前，应用程序数据必须存储在cookie中，并包含在每个服务器请求中。大量数据可以存储在本地，而不会影响网站性能。尽管localStorage更现代，但这两种技术都有其优缺点。

饼干

优点

旧版支持（一直存在）
持续数据
到期日期

缺点

每个域都将其所有cookie存储在单个字符串中，这可能会使解析数据变得困难
数据未加密，这成为一个问题，因为... ...尽管大小很小，但每个HTTP请求都会发送cookie限制大小（4KB）
可以从cookie执行SQL注入

本地存储

优点

大多数现代浏览器的支持
永久性数据直接存储在浏览器中
同源规则适用于本地存储数据
并非与每个HTTP请求一起发送
每个域约5MB的存储空间（即5120KB）

缺点

以前不支持的任何版本：IE 8，Firefox 3.5，Safari 4，Chrome 4，Opera 10.5，iOS 2.0，Android 2.0
如果服务器需要存储的客户端信息，则必须有目的地发送它。

localStorage用法与会话一的用法几乎相同。它们有很多精确的方法，因此从会话切换到localStorage确实是小孩子的玩法。但是，如果存储的数据对于您的应用程序确实至关重要，则在localStorage不可用的情况下，您可能会使用cookie作为备份。如果要检查浏览器对localStorage支持，则只需运行以下简单脚本即可：

/* 
* function body that test if storage is available
* returns true if localStorage is available and false if it's not
*/
function lsTest(){
    var test = 'test';
    try {
        localStorage.setItem(test, test);
        localStorage.removeItem(test);
        return true;
    } catch(e) {
        return false;
    }
}

/* 
* execute Test and run our custom script 
*/
if(lsTest()) {
    // window.sessionStorage.setItem(name, 1); // session and storage methods are very similar
    window.localStorage.setItem(name, 1);
    console.log('localStorage where used'); // log
} else {
    document.cookie="name=1; expires=Mon, 28 Mar 2016 12:00:00 UTC";
    console.log('Cookie where used'); // log
}

有人注意到， “安全（SSL）页面上的localStorage值是隔离的” ，请记住，如果您从“ http”安全协议转换为“ https”安全协议，则该cookie仍可访问，则localStorage将不可用。如果您使用安全协议，请务必注意这一点。

#4楼

在JWT的上下文中 ，Stormpath写了一篇相当有帮助的文章，概述了存储它们的可能方法以及与每种方法有关的（缺点）优点。

它还简要概述了XSS和CSRF攻击，以及如何应对它们。

我在下面附上了一些简短的摘录，以防他们的文章脱机/其站点出现故障。

本地存储

问题：

Web存储（localStorage / sessionStorage）可通过同一域上的JavaScript访问。这意味着您网站上运行的所有JavaScript都可以访问Web存储，因此，它很容易受到跨站点脚本（XSS）攻击的攻击。简而言之，XSS是攻击者可以注入将在您的页面上运行的JavaScript的一种漏洞。基本的XSS攻击会尝试通过表单输入注入JavaScript，攻击者会在其中输入警报（“您被黑”）；转换为表单，以查看它是否由浏览器运行并且可以被其他用户查看。

预防：

为了防止XSS，常见的响应是对所有不受信任的数据进行转义和编码。但是，这还远没有完整。 2015年，现代网络应用使用托管在CDN或外部基础架构上的JavaScript。现代网络应用程序包括用于A / B测试，渠道/市场分析和广告的第三方JavaScript库。我们使用Bower等软件包管理器将其他人的代码导入我们的应用程序。

如果只破坏了您使用的一个脚本怎么办？恶意JavaScript可以嵌入到页面中，并且Web存储受到损害。这些类型的XSS攻击可能会导致所有人在不知情的情况下访问您站点的Web存储。这可能就是为什么许多组织建议不要在网络存储中存储任何有价值的东西或信任任何信息的原因。这包括会话标识符和令牌。

作为一种存储机制，Web存储在传输期间不会强制执行任何安全标准。读取并使用Web存储的任何人都必须进行尽职调查，以确保他们始终通过HTTPS发送JWT，而不通过HTTP发送JWT。

饼干

问题：

与HttpOnly cookie标志一起使用时，cookie无法通过JavaScript访问，并且不受XSS的影响。您还可以设置安全cookie标志，以确保仅通过HTTPS发送cookie。这是过去曾利用Cookie存储令牌或会话数据的主要原因之一。现代开发人员不愿使用Cookie，因为传统上他们要求将状态存储在服务器上，从而破坏了RESTful最佳实践。如果将JWT存储在cookie中，则cookie作为一种存储机制不需要在服务器上存储状态。这是因为JWT封装了服务器处理请求所需的所有内容。

但是，cookie容易受到其他类型的攻击：跨站点请求伪造（CSRF）。 CSRF攻击是一种攻击，当恶意网站，电子邮件或博客导致用户的Web浏览器在当前已对其进行身份验证的受信任站点上执行有害操作时，会发生这种攻击。这是对浏览器如何处理Cookie的一种利用。 Cookie只能发送到允许它的域。默认情况下，这是最初设置cookie的域。无论您是在galaxies.com还是hahagonnahackyou.com上，都会发送Cookie进行请求。

预防：

可以通过使用同步令牌模式来防止CSRF。这听起来很复杂，但是所有现代Web框架都对此提供支持。

例如，AngularJS提供了一种解决方案来验证cookie仅可被您的域访问。直接来自AngularJS文档：

执行XHR请求时，$ http服务从cookie（默认情况下为XSRF-TOKEN）读取令牌，并将其设置为HTTP标头（X-XSRF-TOKEN）。由于只有在您的域上运行的JavaScript才能读取Cookie，因此可以确保您的服务器XHR来自在您的域上运行的JavaScript。通过包含xsrfToken JWT声明，可以使此CSRF保护成为无状态的：
{ "iss": "http://galaxies.com", "exp": 1300819380, "scopes": ["explorer", "solar-harvester", "seller"], "sub": "tom@andromeda.com", "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e" }
利用Web应用程序框架的CSRF保护，cookie可以坚固地存储JWT。通过检查API中的HTTP Referer和Origin标头，也可以部分阻止CSRF。 CSRF攻击将具有与您的应用程序无关的Referer和Origin头。

完整的文章可以在这里找到： https : //stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

关于令牌本身的结构，他们还提供了有关如何最佳设计和实现JWT的有用文章： https ://stormpath.com/blog/jwt-the-right-way/