一份漏洞报告写得含糊，漏洞修复的报告人就得靠猜。猜错了，模板要么改出别的漏洞问题，要么干脆没改到点上。报告我见过最离谱的模板一份报告，标题写“某页面存在安全问题”，漏洞正文只有一句话：“点击按钮后可能有问题。报告”没了。模板开发拿到这份东西，漏洞除了骂人什么也做不了。报告

漏洞报告不是模板写给提交者自己看的备忘，是漏洞给另一个工程师的行动指令。指令必须可执行。报告可执行的模板前提是：能复现、能定位、能验证。

先让人复现出来

复现步骤是报告的命根子。别写“登录后进入某页面”，要写清楚：用什么账号、什么权限、从哪个URL进入、点了哪个按钮、输入了什么内容、观察到了什么响应。请求和响应如果能贴，就贴。Burp的原始报文比任何文字描述都精确。

我习惯把复现步骤写成编号列表。每一步只做一件事。比如：

1. 使用普通用户账号登录 2. 访问 /api/user/profile?uid=1001 3. 将 uid 改为 1002 4. 响应中返回了 1002 用户的手机号和邮箱

四步，没有废话。任何人照着做都能看到同样的结果。这就够了。

影响要具体，别吓唬人

“可导致严重安全问题”这种话等于没说。严重到什么程度？能拿到什么数据？能操作什么功能？影响多少用户？

写影响的时候，我一般分两层。第一层是技术影响：越权读取了用户敏感信息，接口未校验当前用户与目标用户的关系。第二层是业务影响：攻击者可以批量遍历uid，获取全站用户的手机号和邮箱，用于撞库或诈骗。

技术影响帮开发定位问题，业务影响帮负责人判断优先级。两个都写，别偷懒。

修复建议不是必须的，但很有用

有些报告只提交问题，不提修复方案，这本身没问题。但如果你对这块代码比较熟，或者知道类似的漏洞之前怎么修的，写一句建议能省很多沟通成本。

比如上面那个越权，可以补一句：“建议在接口层增加当前会话用户与uid的归属校验，不要仅依赖前端传参。”不用写具体代码，方向对了就行。开发不一定照做，但至少知道你想到了哪一层。

定级这件事，别自己加戏

漏洞等级按公司或平台的规则来。没有规则就按CVSS粗算，别凭感觉写“高危”。我见过把反射型XSS定成严重的，也见过把SQL注入定成中危的。定级离谱，要么被驳回，要么浪费应急资源。

不确定的时候，写清楚利用条件和前提。比如“需要用户登录并主动点击链接”，这本身就是降级因素。把事实摆出来，让定级的人去判断。

一个真实的对比

之前审过两份报告，都是同一个越权漏洞。第一份写了三百字，绕来绕去，开发看了半小时才明白问题在哪。第二份只有八十个字，附了一张请求截图和一张响应截图，开发五分钟就定位到了代码行。第二份的报告人后来跟我说，他写的时候就想一件事：怎么让看的人少动脑子。

这个思路是对的。漏洞报告的本质是信息传递，不是文学创作。越短、越准、越直接，越好。

最后说一个细节：标题。别写“越权漏洞”，写“/api/user/profile 接口未校验uid归属导致越权读取用户信息”。标题里带上接口路径和漏洞类型，搜索和归档的时候会感谢你。