对于RESTful规范服务是否须要办法跨站申请攻打，网上有很多探讨，总结下来外围的关键点在于是否应用了cookie，而就目前而言，REST规范下的服务接口，即使API做到了无状态，用户令牌（Token）也很常常会放到localStorage或者cookie中，这些状况下实质上与RESTful的无状态规范定义不抵触，然而必须要思考XSS（跨站脚本攻打）、CSRF（跨站申请攻打）的防备需要了。
Cookie中有个HttpOnly的属性，如果没有设置为true，应用js脚本能够拿到其中存储的内容，歹意页面可能会通过嵌入代码拿到用户未爱护的cookie值，如果存储的是用户敏感身份信息，并且网站服务没有更多的保护措施，那么黑客便能够伪造用户的身份随心所欲了。localStorage同样存在XSS平安危险，因而不利用来存储敏感数据。
CSRF在用户关上了黑客的歹意页面时产生，通过简略的嵌入<img>标签或者iframe，能在用户无感知的状况下应用用户的cookie数据拜访其余网站的GET、POST接口服务，尽管黑客得不到被爱护cookie中的值，甚至无奈解析响应报文内容，然而接口的随便伪造调用带来的危险微小。因而个别状况下网站服务须要思考csrf的平安防护。
但如果是REST规范的API服务方呢？
在REST规范下，GET办法不会产生数据批改，最多会产生一些额定的日志数据和网络流量，因而对于GET申请无需对csrf布防。而POST办法须要思考其容许的Content-Type，如果仅反对application/json格局，那么嵌入的iframe页面中的form提交产生的form-data或者form-urlencoded申请无奈胜利，而应用XmlHttpRequest发动的post申请，因为浏览器的同源策略，又会要求发动预检（preflight）申请，因而也不可能胜利。而其余Patch、Delete、Put办法的申请，既不能通过iframe达成，也无奈跳过预检申请步骤，因而在仅反对application/json的POST状况下，RESTful接口提供服务方能够不必思考csrf平安防护。
凡事无相对，在网上有一篇通过flash达成对application/json接口进行csrf攻打的办法 : 服务的校验Content-Type，只接管application/json格局的CSRF绕过办法。
不过思考到支流浏览器对flash的反对均已下线，怎么说呢...
Otherwise，就不得不思考进攻下csrf攻打了。如果面临这种需要，能够从以下办法着手：
- 验证申请Referer，对于应用非IE6非hack版本奇葩浏览器的失常用户，拦挡下申请的Referer，只容许受信赖的起源方发动的申请，基本上就是改变最小成果最快的csrf进攻伎俩了。
- 思考下用户token真的须要保留到cookie中吗？如果敞开浏览器就完结会话，下次从新登录能够接管，那就不要写cookie了；如果用户须要主动续签token，要做到无感知主动登录，能够写个refresh_token用来在下次申请时从新续签token（从新生成），这个token数据就存在浏览器内存变量中，而后在后续申请中携带上新的token信息，而不是写到cookie里。
- otherwise，用csrfToken，用户登录胜利后，或者验证身份胜利后，生成一个随机csrfToken给前端，后续申请时带上这个。csrfToken不必验证身份，只需判断是否是实在签发过的就行，能够简略放到redis汇合数据中。