Cookie时Web服务端发送给用户但浏览器的一小段数据，浏览器会存储这些数据并且在后续发往服务器的请求中带上它们。(是一种将数据存储在客户端的方式)
cookie分类：
第一方Cookie：
First-Party Cookie，是指用户当前访问的网站直接植入的Cookie，通常时网站用于正常功能的Cookie，便于使网站记住用户的偏好设置。
第三方Cookie
Third-Party Cookie，当用户访问一个网站时，如果这个网站加载了其他网站的资源，此时其他网站植入的Cookie就称为第三方Cookie。
注意：第一方和第三方Cookie是相对的概念，我们是根据用户是直接访问网站还是通过外部网站嵌入访问来决定该网站是第一方还是第三方。比如我有 a.com, 其中有一个ad.com广告网站，那么我访问a.com上的ad.com就是访问第三方Cookie，如果直接访问ad.com就是访问第一方Cookie
联想：网站个性化广告的投放
我在浏览第一个网站时关注了某个物品，当我到另外一个网站，会推送给我那个物品的广告，就是这两个网站拥有相同的第三方Cookie。
所有浏览器都会接收第一方Cookie，但是浏览器隐私策略可能会阻止部分第三方Cookie。
Cookie属性
-
Domain属性：
-
指定Cookie在哪些域名中生效，即访问哪些域名会发送这个Cookie，也决定了哪些域名的网页可以通过JavaScript访问这个Cookie。
-
如果域名前带 ‘ . ’ 号，表示该Cookie对当前域名及其子域名都有效。如果不带仅在当前域名有效。
-
如果在服务端通过Set-Cookie 写入Cookie时，不指定Domain属性，Cookie的生效范围仅限于当前域名，Host-Only Cookie。
-
目前主流浏览器都遵循RFC 6265规范，在 Set-Cookie 或 JavaScript 中写入Cookie时只要加入了Domain属性，即使没有点号 “ . ”前缀，它也不是 Host-Only Cookie。
-
注意：Cookie的域名隔离不受端口的限制，须评估使用该域名不同端口的web应用的安全性
-
-
Path属性：
-
用于指定Cookie生效路径，只有访问这个路径时，浏览器才会发送这个Cookie。
-
如果不设置Path，默认值就是当前页面所在路径。
-
不能依赖Path来做安全隔离，因为在浏览器中一个路径页面可以使用ifram嵌入另一个路径页面，而这两个页面为同源，他们之间DOMD可以互相访问，所以一个页面可以读取另一个页面的Cookie
-
-
Expries属性：
-
服务端可以通过Expires属性来设置Cookie的有效期，浏览器会在这个Cookie到期后自动将其删除。
-
没有指定Expries属性的Cookie叫做“临时Cookie”，在关闭浏览器后将自动删除。
-
设置了有效期的Cookie，浏览器并不能保证他在有效期内不被删除，因为浏览器对Cookie的存储存在一个上限，超过这个上线，会删除旧的Cookie。
-
-
HttpOnly属性：
-
说明Cookie只能用于HTTP/HTTPS传输，客户端JavaScript无法读取它。
-
-
Secure属性：
-
给Cookie设置该属性后，Cookie指挥在HTTPS亲求种被发送给服务器，非加密HTTP请求是不会发送该Cookie的。
-
-
SameSite属性：
-
SameSite是一个新的安全属性，服务端在 Set-Cookie响应头中通过SameSite属性指定是否可以在跨站请求中发送该Cookie，即它能不能作为第三方Cookie。
-
None：
-
不做限制，任何场景下都会发送Cookie。但是当SameSite被设置为None时，要求Cookie带上Secure属性，即只能在HTTPS协议中发送。
-
-
LAX：
-
在普通的跨站请求中都不发送Cookie，但是导航到其他网站时(点击连接)会发送Cookie。
-
在跨站点提交表单的场景中，只有GET方法提交的表单会带Cookie。
-
-
Strict：
-
完全禁止在跨站请求中发送Cookie，即使点击站外链接也不会发送Cookie，只有当请求的站点与浏览器地址栏中URL中域名属于同一个站点时才会发送Cookie。
-
由于会影响到用户体验，使用非常少。
-
-
-
SameParty属性：
-
即允许企业将多个网站定义成一个可信站点集合，称为First-Party Sets。当一个网站请求另一个网站资源时，浏览器会检测这两个网站是否同处一个First-Party Sets，如果是带有SameParty 属性的第三方Cookie也会被带上。
-
-
Cookie前缀：
-
在存在子域名的网站中，每个站点可以通过设置Cookie的Domain属性，写入一个让所有子域名都可见的Cookie。这将带来一定的混乱，每个站点都无法确定一个Cookie是不是自己写入的。
-
_Host-
-
服务端通过 Set-Cookie 头设置 Cookie，或者前端脚本通过 document.cookie 属性设置Cookie时，只有满足以下四个条件浏览器才接受：
-
带有Secure属性
-
不包含Domain属性
-
Patj属性为“ / ”
-
当前为HTTPS链接
-
-
-
_Secure-
-
只有带Secure属性且当前连接为HTTPS浏览器才会接受，是一个约束更少的弱化版本。
-
-
-
保密性和完整性
在Web服务器角度来看，Cookie是对用户完全公开的，应该把Cookie当作不可信的外部输入数据，不能用Cookie数据来做关键的判断。
会话安全
在Web应用中，会话的本质是标识不同的访问者，记录他们的状态，攻击者如果窃取或者伪造了一个会话标识就相当于盗取一个账号身份。
会话管理
会话ID最基本的要求是随机性。
过期和失效
由于Cookie中有效时期访问者可以任意修改Expires属性，所以超时机制应该在服务端实现的。
绑定客户端
如果将绘画与客户端绑定会更安全，即使SessionID被窃取也无法在新的设备中登录目标网站。(QQ异地登录？)
另一个更安全的做法是在登录时将会话与访问者的IP地址绑定，但是会影响用户体验。
安全传输
现代Web应该基本上都是将SessionID写入到Cookie中，所以设置相应的Cookie安全属性非常重要，大多数情况下，建议开启HttpOnly和Secure属性。
