问答 在 UI 界面上,当订单为某个状态时是不允许修改或删除的 (删除按钮变为禁用状态),但直接通过接口传参的话可以进行删除或修改,这种算是接口 bug 么

97年的呢。 测试交流1 171字数 22阅读0分4秒阅读模式

从接口测试来说,传入参数,预期删除,似乎也没有问题。。 文章源自玩技e族-https://www.playezu.com/180580.html

 
    • frankxii
      frankxii 9

      是 bug,既然前端都做了删除禁用,业务逻辑上当然是不能删除订单的,后端也要保持一致,只是后端没有去做这样的校验而已。健康的系统是必须前后端都做好校验的,可以反馈给开发,看他改不改,正常来说改一下也没有多大难度。如果是内部使用的工具,他也不想改,风险可控的话,可以抛出来让研发组长之类的人去做决定,看是否需要修复。有道理,不过风险确实小,像这种没做校验的接口还有很多。。几年下来都没因为这个出过问题,所以倍感纠结 安全无小事,订单就更严重了,这种必须要改,不然出了资损测试一样背锅~
      当然最可悲的不是测试没发现问题而背锅,而是发现了开发不改而背的锅,到时候说你不坚持、没立场……是 bug,这个是业务规则漏洞。前后端应该要保持一致。

      没出问题 != 没有问题,不知道你这里具体业务场景是啥,但既然不允许删除订单,那应该是业务规则是基于此时订单无法删除来设计的。那如果此时实际出现了订单删除,我理解你其它业务逻辑也可能会跟着一起出错,甚至连整个帐一起出错,到时候修起来就非常累了。

      当然一步到位全部发现全部改好很难,可以按安全风险一批一批检查和修改,但这个风险要明确暴露出来,让项目团队明确知道,并进行评估决策。资损分析中的一点。这个就要看需求了。服务端逻辑和前端逻辑是应该保持一致的,这种也是安全问题,可以篡改安全漏洞:越权修改要看,比如你们接口都是 rsa 加密的,我觉得也没什么大问题

    匿名

    发表评论

    匿名网友
    确定

    拖动滑块以完成验证