前端主要面临俩种类型的威胁
1.XSS（Cross Site Scripting）
攻击方式：恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意攻击用户的特殊目的。
2.CSRF（Cross-site request forgery跨站请求伪造，也被称为“one click attack”或者session riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
攻击例子：
假如有一个网站拥有转账功能（某个第三方支付提供的接口），我在该网站注册一个用户，然后给其他用户发送私信，私信内容包括“<img href='test?do=tranfer_money&to=someone&amout=100000" />” 。如果该网站直接输出该内容，用户打开此私信，图片加载的同时就意味着以当前用户状态发送了转账请求。若是转账接口直接信任该用户的请求,就会直接把钱转给别人了。
这里有俩个问题：
1.没有对图片地址进行适当的过滤（XSS）
2.被请求的服务器没有进行严格的认证(CRFS)
问题解决
解决CSRF攻击的思路分如下两个步骤
- 增加攻击的难度。GET请求是很容易创建的，用户点击一个链接就可以发起GET类型的请求，而POST请求相对比较难，攻击者往往需要借助JavaScript才能实现；因此，确保form表单或者服务端接口只接受POST类型的提交请求，可以增加系统的安全性。
- 对请求进行认证，确保该请求确实是用户本人填写表单或者发起请求并提交的，而不是第三者伪造的。
一个正常用户修改网站信息的过程如下
- 用户请求修改信息(1) -> 网站显示用户修改信息的表单(2) -> 用户修改信息并提交(3) -> 网站接受用户修改的数据并保存(4)
而一个CSRF攻击则不会走这条路线，而是直接伪造第2步用户提交信息
- 直接跳到第2步(1) -> 伪造要修改的信息并提交(2) -> 网站接受攻击者修改参数数据并保存(3)
只要能够区分这两种情况，就能够预防CSRF攻击。那么如何区分呢？ 就是对第2步所提交的信息进行验证，确保数据源自第一步的表单。具体的验证过程如下：
- 用户请求修改信息(1) -> 网站显示用于修改信息的空白表单，表单中包含特殊的token同时把token保存在session中(2) -> 用户修改信息并提交，同时发回token信息到服务端(3) -> 网站比对用户发回的token和session中的token，应该一致，则接受用户修改的数据，并保存
这样，如果攻击者伪造要修改的信息并提交，是没办法直接访问到session的，所以也没办法拿到实际的token值；请求发送到服务端，服务端进行token校验的时候，发现不一致，则直接拒绝此次请求。
参考
淘宝UED： 前后端分离模式下的安全解决方案