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

好问题。

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

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

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

:flushed: 使用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敏感度设计的就会高一些，毕竟对于别有用心的人来说，小程序对他们是完全透明的，所谓的加密数据、接口都是浮云。

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