共计 1472 个字符，预计需要花费 4 分钟才能阅读完成。
对于 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 汇合数据中。
