一、️ CORS
1.1 为什么会跨域
出于浏览器的同源策略限制，浏览器会拒绝跨域请求。
同源： 域名、端口、协议都相同，称为同源。
例如以下地址都不同源：
www.domian.com // 协议不同
www.domain.com:30001 // 端口不同
一般情况下，浏览器碰到请求是这么玩儿的：
- client发送请求，请求头加上origin字段表示发送请求的源。
- server端响应请求，浏览器接到响应报文，一看，当前页面origin和server origin不同源，拒绝该请求
简单请求直接发送GET/POST请求，非简单请求发送OPTIONS请求检查请求头。
所以我们会发现，在前后端分离的项目中，我们的服务一般是布在不同的服务器上，或是同一台服务器的不同端口，这个时候我们去调用接口，就会出现跨域问题。
当然，script标签，img、video等等都不受同源策略限制，否则你的网站上都没有办法加载其他地方的图片了。
1.2 CORS解决跨域原理
了解了跨域产生的原因，我们可以想到，可不可以和浏览器约定，对于在返回的请求报文里添加一些信息，告诉她某些地址可以绕过同源策略。
CORS跨域就是这个原理，你可以在服务器端添加一个Access-Control-Allow-Origin表示可以接受的跨域请求源。
假设你的client起在 domaina.com:3000，server起在domian2.com:8080，在server端设置了响应报文头为Access-Control-Allow-Origin:domaina.com
- Client 发送请求到server端
- server端给响应报文添加
Access-Control-Allow-Origin:domaina.com - client浏览器收到响应报文，看到有
Access-Control-Allow-Origin字段，从当前client地址domaina.com:3000去匹配，发现当前地址是被允许跨域的，于是返回响应。
1.3 CORS的安全问题
当你的响应头设置为Access-Control-Allow-Origin:*表示对于这个响应报文所有的都支持跨域，这样就不用一个一个手动配置了
但是这样会一些问题，假设这样一个场景
公司内网有个接口 domainA.com/bill/queryBill ，这个接口可以查询全公司人的工资流水，这个接口允许跨域的端口为*。
攻击siteA请求了这个接口，获得了响应，由于所有的网站都允许跨域，所以浏览器允许了这次行为，攻击者获得了全公司人的工资账单。
所以为了安全起见，还是需要手动配置白名单。
二、️ XSS攻击
xss攻击（跨站脚本攻击）是利用网站漏洞，向网络中注入恶意代码，当其他用户浏览网页时，该代码就会执行，从而达到攻击。
2.1 反射性
一般是引诱用户点击链接跳转到某些页面，然后攻击者可以在跳转页面中注入任意恶意代码，如窃取你的cookie之类的
2.2 存储型
这类攻击脚本会被存到服务器的数据库中，所有用户加载这个页面的时候都会执行攻击代码，例如一些论坛的留言，在输入框中插入script脚本。
还有可能对DOM进行改造，例如img标签的URL，如果把地址改成了'' onclick=alert(/xss/)，这样src属性提前关闭，并注入了一段恶意脚本。
2.3 防范
-
输入检查，对双引号，尖括号进行转译。
const decodingMap = { '<': '<', '>': '>', '"': '"', '&': '&', ' ': '\n' } -
HttpOnly属性，通过这个属性，js脚本将不能操作cookie，只有服务器可以对cookie进行操作。
三、️ CSRF
3.1 CSRF原理
跨站请求伪造，是一种劫持受信任用户向服务器发送非预期请求的攻击方式。
举个🌰，公司的运营平台有个接口domain-a.com/api/bill/update/:id，可以更改用户的工资。
攻击者构造一个钓鱼网站domain-b.com，在页面中构造一个img标签，地址指向domain-a.com/api/bill/update/1234。他将这个链接嵌入运营平台或者以某种方式引诱管理员打开，当超级管理员打开了这个页面，解析到img标签的时候就会发起请求，由于超管已经登陆过了这个页面，cookie中有他的信息，这次请求也会携带上这个cookie，因此这个接口就被调用，工资数据就被修改了。
3.2 Referer check
referer请求头字段可以说明发起请求的site，例如在domain-a.com发起请求的时候，referer=domain-a.com，在domain-b则是domain-b，因此我们可以对referer校验，仅有合法的domain可以调用接口。
但如果你的接口只提供底层能力，并不知道上游业务方是谁，则可以使用token验证。
3.3 csrf token
跨站请求之所以可以伪造身份，是因为cookie存在client端，每次请求都会自动携带，我们只需要在请求里加一个无法保存或者伪造的token，就可以解决这个问题。
可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。
比如对与post请求，可以在表单上添加一个<input type=”hidden” name=”csrf-token” value=”tokenvalue”/>或者通过xhr请求中添加X-CSRFToken请求头，这段操作的代码将写在客户端上。
