看你的控制力了

比如 你可以把前后台都布置在一个虚网里 后台只接收内网的请求 开口只通向前台

【 在 iwannabe 的大作中提到: 】
: 换个说法，怎么禁止postman直接调试生产环境的后端，懂了吗
:
--
FROM 47.144.177.*

一切暴露在公网上的访问端口，都要满足安全要求，这和前后端没关系。 做不到你们的架构师背锅吧。
1. 不希望别人用到的功能，发布到生产环境干嘛？
2. 前后端都要做认证授权检查这不是最基本的要求吗? 除非是故意允许公开访问的请求。 别说框架不支持，这是纯扯蛋。 只不过前端的认证是密码/mfa之类面向人的，后端是sessionid, token之类有时效性面向代码的。
3. 本地起一个前端连远程后端是前端开发的基本方式，没啥不对的。
4. 你本地起一个前端，如果能通过认证，后端谁也拦不住你。甚至在生产上拿到了认证信息直接curl就行，根本不用另起前端。但是做权限控制的时候好好设计，为什么开发能有生产环境的相关权限？ 权限控制做好了即使认证过了你也啥也干不了.
5. 最后，后端的审计系统是摆设么？你要是能伪造别人登录，那是另外的故事了。
--
修改:RolandCR FROM 111.201.128.*
FROM 111.201.128.*

防重放攻击吧
譬如系统的一个接口，允许正常用户通过页面访问，但是不允许用户绕过页面高频访问，因为很可能会打爆后端存储。或者可以对系统提交产生负面风险的数据，页面有校验，但是用户自己手写内容去提交的话，量大了之后容易产生系统压力风险，或者提交内容虽然符合技术校验规范，但是属于不建议的业务场景。

简单来说，用户用脚本刷单，怎么限制。这个刷单可以不是高频的，也可以不是同一个登录账号
【 在 iwannabe 的大作中提到: 】
: 换个说法，怎么禁止postman直接调试生产环境的后端，懂了吗
--
FROM 124.77.252.*