从接口测试来说，传入参数，预期删除，似乎也没有问题。。 文章源自玩技e族-https://www.playezu.com/180580.html
玩技站长微信
添加好友自动发送入群邀请
rainbow-shownow
玩技官方公众号
官方微信公众号
PLAYEZU
- 版权提示：本站仅供存储任何法律责任由作者承担▷诈骗举报◁▷新闻不符◁▷我要投稿◁
风险通知：非原创文章均为网络投稿真实性无法判断，侵权联系2523030730
免责声明：内容来自用户上传发布或新闻客户端自媒体，切勿！切勿！切勿！添加联系方式以免受骗。 - 原创转载：https://www.playezu.com/180580.html
转载说明： 点我前往阅读>>>
未知地区 1F
是 bug，既然前端都做了删除禁用，业务逻辑上当然是不能删除订单的，后端也要保持一致，只是后端没有去做这样的校验而已。健康的系统是必须前后端都做好校验的，可以反馈给开发，看他改不改，正常来说改一下也没有多大难度。如果是内部使用的工具，他也不想改，风险可控的话，可以抛出来让研发组长之类的人去做决定，看是否需要修复。有道理，不过风险确实小，像这种没做校验的接口还有很多。。几年下来都没因为这个出过问题，所以倍感纠结 安全无小事，订单就更严重了，这种必须要改，不然出了资损测试一样背锅~
当然最可悲的不是测试没发现问题而背锅，而是发现了开发不改而背的锅，到时候说你不坚持、没立场……是 bug，这个是业务规则漏洞。前后端应该要保持一致。
没出问题 != 没有问题，不知道你这里具体业务场景是啥，但既然不允许删除订单，那应该是业务规则是基于此时订单无法删除来设计的。那如果此时实际出现了订单删除，我理解你其它业务逻辑也可能会跟着一起出错，甚至连整个帐一起出错，到时候修起来就非常累了。
当然一步到位全部发现全部改好很难，可以按安全风险一批一批检查和修改，但这个风险要明确暴露出来，让项目团队明确知道，并进行评估决策。资损分析中的一点。这个就要看需求了。服务端逻辑和前端逻辑是应该保持一致的，这种也是安全问题，可以篡改安全漏洞:越权修改要看，比如你们接口都是 rsa 加密的，我觉得也没什么大问题