我理解的：后端不应该信任前端，对于接收到的请求应该进行严格的验证。 但是如果这样做的话，前端在给后端发请求前，会对参数做一次检查，然后后端接收到请求后，还要在做一次更严格的检查，好麻烦啊。。。
所以我想请教一下，如何设计一个架构，让后端信任前端，或者在后端过滤掉不可信的请求或第三方请求？
最初想的是使用跨域限制，后来发现太容易伪造一个请求了。。。不可行 然后想加上HTTPS，但是个人能力有限，还不会伪造HTTPS请求，但是直觉上感觉这也不可行。。。
望各位不啬赐教~
谢谢！
----------------------- update ------------------------- 上面表述的可能不太清楚，其实这个问题的是想寻求一种可以省去每次接收到请求后都要对请求参数做各种验证的方法，感觉好麻烦。。。所以想保证我的后端服务只对我的前端提供服务，这样前端按照与后端的约定进行传参，后端便不再对参数进行检查 （其实我也感觉我这偷懒的想法有些可笑。。。）
或者有没有一种比较优雅、比较工程化的方式来进行参数验证呢？ （已知：express-validator、joi、validator.js、node-simple-schema，有没有更好的呢？）
回复 (14)
服务器验证每次请求这是必须的逻辑吧？最少我们设计的客户端每次请求都不可信，必须检查。
OAuth 客户端模式 (Client Credential)
@zmecust 我的理解：这种模式是前端向后端请求一个认证标识(access_token)，然后前端会保存这个token，后端通过这个token判断身份。但是这个token如果在前端保存的话，是所有人可见的，也就容易被窃取，也就会伪造请求，这样也不安全
OAuth或者自定义的加密sign，如果担心OAuth的token泄露，可以缩短token有效期。
或者使用更加简单的办法，使用 加密的sign，具体可参考淘宝开发平台的API加密sign，基本不能伪造，因为每次请求的sign不同
同问
网易云音乐 API 这么强的加密都被人挖出来
加了 https 照样可以用 Charles 抓
试试客户端和服务端数据传输都用非对称加密。。。。。
signature，也就是客户端跟服务端定义一套协议，发送前客户端要根据发送的 body 生成一个签名，服务端收到后，验证签名 这里的关键其实就是签名的生成规则（这个不可公开）
未登录就只有访客权限，登录就有用户权限。如何保证请求已登录用户发出的，用户登录后请求里会带有sessionId，这个sessionId会过期。
我理解的：后端不应该信任前端，对于接收到的请求应该进行严格的验证。
对的。
但是如果这样做的话，前端在给后端发请求前，会对参数做一次检查，然后后端接收到请求后，还要在做一次更严格的检查，好麻烦啊。。。
前端做检查只是为了“体验”，又不是必需的，觉得麻烦不做就好了，只处理服务端的响应，如果有什么错的情况下。
所以我想请教一下，如何设计一个架构，让后端信任前端，或者在后端过滤掉不可信的请求或第三方请求？
信任前端不代码信息前端发送的数据。信任前端发送的数据不代表这些数据不会造成问题。通过 cookie 验证的请求已经是“受信任”的了。
最初想的是使用跨域限制，后来发现太容易伪造一个请求了。。。不可行 然后想加上HTTPS，但是个人能力有限，还不会伪造HTTPS请求，但是直觉上感觉这也不可行。。。
HTTPS 的目的是防窃取，防串改，跟业务层面的“认证”没关系。
非对称加密，这么折腾，不如上 https 了
@yszou 感谢你详细的回答！我的问题更新了，欢迎你再次回答！
@ImSiegeLion
或者有没有一种比较优雅、比较工程化的方式来进行参数验证呢？
一般配合 ORM ，在作 Model 定义的时候，基本的验证自动就有了的，并且数据修改和添加也是使用 ORM ，所以那些验证的定义也就自己会应用。
这些方面的东西，去 Ruby ，或者进一步说去看看 RoR 怎么作的，一般就是最工程化的方案了。当然，前提是在你使用的工具中，有相关的基础设施。