关于前后端分离，后端对前端数据安全校验的疑问

好问题。

个人理解：如果依赖了浏览器自动发送的凭据（如 Cookie、HTTP 身份验证），那么就要防止 CSRF 攻击，反之可以不用考虑。事实上 CSRF 主要指的是跨站请求伪造，API 的请求可以通过服务器的一些策略进行相应处理。

另外，加了 sign 不也是可以通过 js 计算出来么

您好，童鞋，关于 token 的设计，主要看你们公司对项目的设计，你可以选择类似 jwt 这样的 token 方式，可以通过设置较短的有效期，你也可以设计带签名，时间戳，密钥，或者 appkey 那些方式，来设计 token，甚至，如果你的项目，是 laravel 或者其他 php 框架作为后端接口， 同时还有 app、小程序，和 web 端，这样你的接口还可以分层设计，针对不同端的安全情况，来设计 token 的有效期时长，或者 refresh token 的规则等等

使用 https，另外 token 即使获取了，登录了用户端，但是敏感操作需要短信认证

web 端用 jwt 当然要验证接收方的，不过大多都没有这样做，就有泄露风险，做了泄露的风险就要小得多了

https 加密传输；
csrf 是利用请求时浏览器会携带 cookie 的特点来进行攻击，但后端并不是验证 cookie 中的 token，而是 params 中的 token，这就需要拿到 cookie，浏览器不会允许这么做的，因为有这个特点，一般 token 放在 localStorage 中。如果一个网站能够拿到其他网站的 cookie 和 localStorage，就没有安全可言了。

想安全也安全不了，只要能抓到就能伪造请求，包括那个 CSRF 攻击.
可以进行两方面考虑传输数据安全

1. 用 RSA 进行传送数据进行签名，服务器端验证签名，这个防止篡改数据。一旦数据篡改验证签名肯定失败
2. 可以给数据中加入随机的 request_token, 这个 request_token 可以存到缓存里，设置一定的有效期，比如 7 天之类的。同一个请求只能请求一次。这个防止抓包进行请求回放.

首先你要搞清楚什么是 CSRF 攻击，CSRF 是为了传统的 Session 机制，防止跨站请求。
API 接口本身就是开放的，防止跨站的意义是什么？如果 API 还要防 CSRF，那为什么不直接用 Session ？

签名校验是谁校验？谁签名？那肯定是前端签名，后端校验，那签名就可以轻易伪造，这个签名就没有意义，如果后端签名后端校验，那跟 token 也没区别。

还有就是，token 是怎么被泄露的？抛开泄露原因不谈，这就是耍流氓，在前后端分离模式下，token 一旦被泄露就意味着用户身份可以被假冒，现在都是 https 传输，除去中间人攻击外，那就是客户端的问题，就是说 token 一旦泄露，那肯定是用户自愿的。

其实你要考虑一个问题，就是如果 API 也要考虑 CSRF ，那你应该怎么发放 CSRF ？ 这也就是 CSRF 的最基本工作方式，传统的方式 CSRF 是在生成表单的时候就放在页面上了，验证的时候随表单发送，那 API 你该怎么获取这个 CSRF 字符串？

对于一些场景来说，对数据签名可以保证数据的完整，也可以抵挡一些新手爬虫。对于数据安全来说，你的 sign 密钥需要放在本地，那其实没什么太大意义的，直接上 HTTPS 。

非常理解你的疑虑，之前在设计接口的时候也考虑了很久，如何完全避免这种情况。

我的答案是不会有完全解决的完美方案，我们能做的就是尽量提高攻击的成本。

例如

• HTTPS 是必须要上的，这样可以避免中间人攻击，对代码 0 侵入
• 在接口 token 设计的时候，考虑快速切换以及风险识别，例如检测 IP 地址的变更、接口请求频率的监控、WIfi 信息等
• 关键操作做二次验证，例如钱包提现、积分消耗等敏感操作使用短信验证码二次验证
• 前端做验证，例如接入腾讯的滑动验证码或第三方的类似服务

我这对接了微信小程序端、APP、抖音小程序、以及第三方的系统，不同渠道的 token 设计都是不同的，特别是对有小程序来说，token 敏感度设计的就会高一些，毕竟对于别有用心的人来说，小程序对他们是完全透明的，所谓的加密数据、接口都是浮云。

总结一句话：没有一招鲜 只能多方位做验证