去年某电商平台被曝出用户订单信息泄露，软件起因不是测试黑客攻破了防火墙，而是中常测试环境里一个调试接口忘了关。这个接口能直接返回任意用户的安全订单详情，连鉴权都没有。漏洞开发觉得“反正是软件内网”，运维觉得“测试完就下线”，测试结果一拖就是中常三个月。安全漏洞在软件测试阶段被漏掉，安全往往不是漏洞因为技术不够，而是软件因为测试的视角太“功能化”了——只关心按钮能不能点，不关心点了之后服务器会不会把不该给的测试数据吐出来。

注入类漏洞是中常测试里最容易踩的坑。很多测试同学拿到登录框，安全输入正确的漏洞用户名密码，验证能进首页就算通过。但试试在用户名里填 ' OR '1'='1 呢？如果后台还在用字符串拼接SQL，这一下就能绕过认证。更隐蔽的是命令注入，比如文件上传功能，测试时只传 .jpg 和 .png，没人会去传一个 ; rm -rf / 命名的文件。我见过一个真实案例，某内部工具的上传接口把文件名直接拼进 shell 命令做格式转换，测试人员传了个正常文件就收工了，后来有人传了带分号的文件名，服务器直接炸了。

权限校验的缺失比注入更普遍。测试用例通常这么写：用A账号登录，能查到A的订单，通过。但有没有试过用A的token去请求B的订单ID？很多系统只在前端做了按钮隐藏，后端接口拿到订单ID就直接查库返回。去年某SaaS客服系统就这么翻的车——测试只验证了“销售看不到管理员菜单”，但没验证“销售能不能直接调管理员的API”。前端隐藏不是权限，后端不校验就是裸奔。

敏感信息泄露在测试阶段极难被发现，因为测试数据都是假的。但问题出在错误处理上。比如登录失败时，系统返回“用户名不存在”还是“密码错误”？前者能让攻击者枚举出所有有效用户名。再比如接口报错时，直接把堆栈信息、数据库连接串、甚至内网IP返回给前端。测试同学看到报错弹窗，第一反应是提bug说“报错信息不友好”，但没意识到这个“不友好”的报错里藏着 jdbc:mysql://10.0.0.5:3306/prod_db。我见过一个测试环境，所有异常都返回完整堆栈，因为开发觉得“方便调试”。

逻辑漏洞最考验测试人员的“坏心思”。比如优惠券领取接口，测试时点一下领一张，正常。但用Burp Suite抓包，把请求重放一百次呢？很多系统只在前端限制“每个用户限领一次”，后端根本没做幂等。还有密码找回，验证码是4位数字，测试时输入正确的就过了。但有没有试过爆破？有没有试过把手机号改成别人的？某社交App的密码重置接口，测试只验证了“验证码正确能改密码”，没验证“验证码错误次数多了会不会锁定”，结果被人写脚本从0000试到9999，重置了上万账号。

测试环境本身也是重灾区。为了图方便，测试库经常直接拉生产数据，但脱敏做得稀烂。手机号中间四位用星号代替，身份证号却原样存着。更常见的是测试服务器直接暴露在公网，弱口令admin/123456，或者根本没改默认的Tomcat管理后台密码。扫描器一抓一个准。我甚至见过测试环境的Swagger文档没关，所有接口参数、返回结构一目了然，连爆破都省了。

说到底，功能测试是“按剧本走”，安全测试是“掀桌子”。测试人员得学会在输入框里填奇怪的东西，在抓包工具里改数字，在返回包里找不该出现的信息。别只盯着需求文档里的验收标准，多想想“如果我是攻击者，会从哪里下手”。那个电商平台的调试接口，如果测试时多问一句“这个接口谁能访问”，可能就不会有后面的泄露事件了。