本地存储vs Cookie
我想通过将所有Cookie移动到本地存储中来减少我的网站上的加载时间，因为它们似乎具有相同的功能。 除了明显的兼容性问题之外，使用本地存储替换Cookie功能是否有任何优点/缺点（特别是性能方面）？
Cookie和本地存储的用途各不相同。 Cookies主要用于读取服务器端 ，本地存储只能由客户端读取。 所以问题是，在你的应用程序中，谁需要这些数据 - 客户端还是服务器？
如果它是你的客户（你的JavaScript），那么通过一切手段切换。 您通过发送每个HTTP标头中的所有数据来浪费带宽。
如果它是你的服务器，本地存储不是很有用，因为你必须以某种方式转发数据（使用Ajax或隐藏的表单域或其他）。 如果服务器只需要每个请求的总数据的一小部分，这可能是好的。
尽管如此，您仍然希望将会话cookie作为cookie保留。
根据技术差异，以及我的理解：
除了保存数据的旧方式之外，Cookie还会为您提供4096个字节（实际上为4095个）的限制，即每个Cookie。 本地存储大小为每个域5MB - 所以问题也提到它
localStorage是Storage接口的实现。 它存储的数据没有过期日期 ， 只能通过JavaScript清除，或清除浏览器缓存/本地存储的数据 - 不像cookie过期。
在JWTs的背景下 ，Stormpath写了一篇相当有用的文章，概述了可能的存储方法以及与每种方法有关的（dis-）优点。
它还简要介绍了XSS和CSRF攻击，以及如何对付它们。
我附上了以下文章的一些简短摘要，以防他们的文章脱机/他们的网站停止运行。
本地存储
问题：
Web存储（localStorage / sessionStorage）可通过同一个域上的JavaScript访问。 这意味着您网站上运行的任何JavaScript都将有权访问Web存储，并且因此可能容易受到跨站点脚本攻击（XSS）的攻击。 简而言之，XSS是一种攻击者可以注入将在您的页面上运行的JavaScript的漏洞。 基本的XSS攻击尝试通过表单输入注入JavaScript，攻击者在这里输入警报（'你被黑客攻击'）; 转换成表格以查看它是否由浏览器运行并且可以被其他用户查看。
预防：
为了防止XSS，常见的反应是转义和编码所有不可信的数据。 但这远不是完整的故事。 2015年，现代网络应用使用托管在CDN或外部基础架构上的JavaScript。 现代Web应用程序包括用于A / B测试，漏斗/市场分析和广告的第三方JavaScript库。 我们使用像Bower这样的软件包管理器将其他人的代码导入到我们的应用中。
如果只使用其中一个脚本受到攻击，该怎么办？ 恶意JavaScript可以嵌入在页面中，Web存储受到威胁。 这些类型的XSS攻击可以在不知情的情况下获取访问您网站的所有人的网络存储。 这可能是为什么一些组织建议不要在Web存储中存储任何有价值的东西或信任任何信息。 这包括会话标识符和令牌。
作为存储机制，Web存储在传输过程中不执行任何安全标准。 无论谁读取Web Storage并使用它，都必须进行尽职调查，以确保他们始终通过HTTPS发送JWT，而不会使用HTTP。
饼干
问题：
Cookie与HttpOnly cookie标志一起使用时，不能通过JavaScript访问，并且不受XSS影响。 您还可以设置安全cookie标志以保证cookie仅通过HTTPS发送。 这是过去利用cookie存储令牌或会话数据的主要原因之一。 现代开发人员不愿意使用cookie，因为他们传统上要求将状态存储在服务器上，从而打破了RESTful最佳实践。 如果您要在Cookie中存储JWT，则作为存储机制的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/
通过localStorage ，Web应用程序可以在用户的浏览器中本地存储数据。 在HTML5之前，应用程序数据必须存储在cookie中，并包含在每个服务器请求中。 localStorage更安全，大量数据可以存储在本地，而不会影响网站的性能。 尽管localStorage更现代化，但这两种技术都有一些优点和缺点。
饼干
优点
缺点
本地存储
优点
缺点
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将无法使用。 如果您使用安全协议，则需要注意这一点。
链接地址: http://www.djcxy.com/p/44889.html