关于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集合数据中。
