写在前面
chrome要慢慢的强制禁止第三方cookie，由于这个涉及到cookie隐私安全性的。就想到与cookie强相关的跨域和跨站的问题。
跨站（Cross Site）
跨站顾名思义就是两个站之间的访问，经过A去访问B。
假如现在有一个站点A：www.example.top:443 ，那么关于跨站关系参考下表
| 站点B | 表现 | 是否跨站 |
|---|---|---|
| www.remex.com:443 | 不同域名 | 跨站 |
| test.example.top:443 | 子域名不同 | 同站 |
| www.example.top:443 | 协议不同 | 跨站 |
| example.top:443 | www缺省 | 同站 |
| www.example.top:8080 | 端口不同 | 同站 |
基本可以理解为，协议相同，二级域名相同就可以被认为是同站。
跨源（Cross Origin）
源即来源，与站类似却又不同的概念。
假如现在有一个站点A：www.example.top:443 ，那么关于跨站关系参考下表
| 站点B | 表现 | 是否跨站 |
|---|---|---|
| www.remex.com:443 | 不同域名 | 跨源 |
| test.example.top:443 | 子域名不同 | 跨源 |
| www.example.top:443 | 协议不同 | 跨源 |
| example.top:443 | www缺省 | 跨源 |
| www.example.top:8080 | 端口不同 | 跨源 |
| www.example.top:443 | 完全匹配 | 同源 |
| www.example.top | 默认端口缺省 | 同源 |
可以看到，跨源更为严格，必须协议、域名、端口完全匹配才被认定为同源。
安全问题
知道跨站和跨域的概念，我们来简单说一下安全问题。
跨站有CSRF（即，跨站请求伪造），跨域有CORS（即，跨域资源共享）。本质上，他俩都是通过窃取用户Cookie凭证，来去伪造该用户做一些相关操作。
CSRF
因为浏览器的机制，你登陆过的站点浏览器会把你的凭证Cookie给存储下来，当你再次访问的时候避免二次登录，直接从浏览器存储中取出来放至会话中，CSRF就是用了这个逻辑。
假如某个站点A未作安全校验，通过伪造站点B的方式，诱导你点击，来向你登陆过的某个站点发起请求，达到在你不知情的情况下进行修改数据的操作，比如修改密码。此时，你从恶意站点B被偷偷向站点A发起攻击者构造好的请求，便是跨站请求伪造。
CORS
而跨域资源共享，则是在Chrome之前推出的SOP（同源策略）基础上，由于配置不当导致的信息泄露的问题。SOP本质上限制的都是JS发起的请求，form表单并不在限制范围内。
当推出SOP策略后，由于网站本身有很多跨源的需求，比如加载第三方link等等，所以谷歌也是给出了解决方案即CORS，允许你去配置CORS策略来共享一些跨源的资源。但是，由于配置不当，比如来源限制为*（通配符，即任意），那么就可能造成预料之外的安全问题。
比如，站点A在获取用户信息处未配置好严格的CORS策略，那么攻击者可以伪造恶意站点B，向站点A的获取用户信息处通过前端JS发起异步请求，并获取信息存储。用户在登录过的站点A有过登录态，cookie被浏览器存储之后，访问站点B，那么该用户又被偷偷向站点A发起了异步请求，这个阶段浏览器会自动带上A的Cookie，这是浏览器的特性，从而获取用户信息。
假定站点A不存在CORS配置错误，严格限制来源，那么从站点B到站点A就是一个跨源请求，是不可能成功的，是会被浏览器阻断的。但是配置错误为*，就代表默认允许所有来源访问，那么就会出问题。
防范
先说CORS，SOP的策略在一定程度上保护了用户的Cookie被跨站传输恶意利用，只要严格限制CORS，那么在chrome中跨源传输cookie是不可能。
但是，CORS仅仅只能限制住由JS发起的异步请求，而CSRF使用的是form表单是不受CORS限制的。那么怎么防范呢？
在Http数据包中有一个Referer字段，假如通过B向A发起请求时，Referer即来源就是B的域名，所以粗暴的方式就是判断来源域名，或者更安全的一点是关键接口生成随机token，每次都不一样对token进行验证，即http请求中常见的csrf_token，这样的话就可以有效避免CSRF了。