如何保证后端接收到的请求来自受信任的客户端？

@ImSiegeLion

或者有没有一种比较优雅、比较工程化的方式来进行参数验证呢？

一般配合 ORM ，在作 Model 定义的时候，基本的验证自动就有了的，并且数据修改和添加也是使用 ORM ，所以那些验证的定义也就自己会应用。

这些方面的东西，去 Ruby ，或者进一步说去看看 RoR 怎么作的，一般就是最工程化的方案了。当然，前提是在你使用的工具中，有相关的基础设施。

@yszou 感谢你详细的回答！我的问题更新了，欢迎你再次回答！

非对称加密，这么折腾，不如上 https 了

我理解的：后端不应该信任前端，对于接收到的请求应该进行严格的验证。

对的。

但是如果这样做的话，前端在给后端发请求前，会对参数做一次检查，然后后端接收到请求后，还要在做一次更严格的检查，好麻烦啊。。。

前端做检查只是为了“体验”，又不是必需的，觉得麻烦不做就好了，只处理服务端的响应，如果有什么错的情况下。

所以我想请教一下，如何设计一个架构，让后端信任前端，或者在后端过滤掉不可信的请求或第三方请求？

信任前端不代码信息前端发送的数据。信任前端发送的数据不代表这些数据不会造成问题。通过 cookie 验证的请求已经是“受信任”的了。

最初想的是使用跨域限制，后来发现太容易伪造一个请求了。。。不可行 然后想加上HTTPS，但是个人能力有限，还不会伪造HTTPS请求，但是直觉上感觉这也不可行。。。

HTTPS 的目的是防窃取，防串改，跟业务层面的“认证”没关系。

未登录就只有访客权限，登录就有用户权限。如何保证请求已登录用户发出的，用户登录后请求里会带有sessionId，这个sessionId会过期。

signature，也就是客户端跟服务端定义一套协议，发送前客户端要根据发送的 body 生成一个签名，服务端收到后，验证签名 这里的关键其实就是签名的生成规则（这个不可公开）

试试客户端和服务端数据传输都用非对称加密。。。。。

加了 https 照样可以用 Charles 抓

网易云音乐 API 这么强的加密都被人挖出来

同问

OAuth或者自定义的加密sign，如果担心OAuth的token泄露，可以缩短token有效期。

或者使用更加简单的办法，使用 加密的sign，具体可参考淘宝开发平台的API加密sign，基本不能伪造，因为每次请求的sign不同

@zmecust 我的理解：这种模式是前端向后端请求一个认证标识(access_token)，然后前端会保存这个token，后端通过这个token判断身份。但是这个token如果在前端保存的话，是所有人可见的，也就容易被窃取，也就会伪造请求，这样也不安全

OAuth 客户端模式 (Client Credential)

服务器验证每次请求这是必须的逻辑吧？最少我们设计的客户端每次请求都不可信，必须检查。