上周三凌晨两点，全测某电商平台的试报运维在日志里翻到一条奇怪的请求：一个普通用户的购物车接口，返回了另外三个陌生账号的全测收货地址。他没敢声张，试报先复现了一遍——把URL里的全测用户ID从10086改成10087，页面刷新，试报地址栏里蹦出别人的全测手机号和门牌号。这就是试报典型的越权漏洞，水平越权。全测三分钟就能测出来，试报可它在这套系统里躺了至少八个月。全测

Web安全测试报告写出来，试报第一页不该是全测“测试范围”和“风险评估矩阵”。那玩意儿谁看？试报开发不看，产品不看，全测老板更不看。我习惯把最要命的那条发现放在最前面，用粗体、红字，加一句人话解释。比如：“任何登录用户都能通过修改URL参数查看他人订单详情，包括收货地址和电话。”后面再附上复现步骤，三步，截图两张。别写“建议修复”，直接写“必须在下次发版前改掉”。

工具扫出来的东西，别全往报告里塞。某次我用Burp Suite跑完一个后台，报告里列了47个“中危”问题，其中32个是Cookie没设HttpOnly。开发看完只说了一句：“这玩意儿我们能怎样？”后来我学乖了，手动验证一遍，把真正能串联起来利用的挑出来。比如一个反射型XSS，单独看就是个弹窗，但它出现在登录后的搜索框里，配合CSRF就能偷走会话。这种组合拳才值得写进报告，还得画个简单的攻击路径图。

测试过程中拍的截图，别只截请求和响应。把浏览器地址栏、开发者工具里的Network面板、甚至旁边的咖啡杯一起截进去。为什么？证明你是真在浏览器里点出来的，不是拿扫描器瞎跑。有一次我报了一个存储型XSS，开发说“不可能，我们前端转义了”。我把截图发过去，地址栏里明晃晃的alert(1)，旁边还有我桌面上那个裂了缝的马克杯。他沉默了十秒，回了一句：“我看看后端渲染那块。”

风险等级别照搬CVSS。那个分数算起来太机械。一个需要管理员权限才能触发的SQL注入，和一个未授权就能访问的敏感接口，哪个更急？显然是后者。我通常分三档：立刻修（能直接拿数据或拿服务器）、这周修（能配合其他漏洞扩大影响）、下个版本修（信息泄露但利用门槛高）。每档下面直接列URL和参数，别写“某接口”，写“/api/v1/user/export?uid=”。

报告末尾别搞“安全建议”那种空话。写具体操作：“把UserController.java第87行的findById(id)改成findByIdAndTenantId(id, currentTenantId)”。开发拿到就能改，不用猜。我见过太多报告最后写“加强输入验证”，这等于没说。输入验证在哪加？用什么正则？过滤哪些字符？写清楚，哪怕给个代码片段。

最后说个真事。某次测试一个金融App的H5页面，发现登录接口返回的token里带了用户角色字段，而且是base64明文。我改了一下角色从“user”到“admin”，重新请求，直接进了管理后台。报告里我只写了一句话：“token可伪造，普通用户可提权至管理员。”附上修改前后的token对比。当天下午就修了。安全测试报告不是学术论文，它是给干活的人看的。越直接，越有用。