内容摘要：漏洞报告写得烂，比漏洞本身更让人崩溃。我见过太多安全研究员提交的报告，要么是流水账，要么是截图堆砌，要么干脆把整个对话记录贴上去。开发人员看完只想关掉工单，然后默默拉黑你。 一份合格的漏洞报告，核心就

漏洞报告写得烂，漏洞比漏洞本身更让人崩溃。报告我见过太多安全研究员提交的漏洞报告，要么是报告流水账，要么是漏洞截图堆砌，要么干脆把整个对话记录贴上去。报告开发人员看完只想关掉工单，漏洞然后默默拉黑你。报告

一份合格的漏洞漏洞报告，核心就一句话：让一个完全不了解背景的报告人，能一步步复现你的漏洞发现。别指望对方具备和你一样的报告前置知识。你花三天逆出来的漏洞逻辑，别人可能连那个模块都没碰过。报告

拿我最近收到的漏洞一份报告举例。提交者写“在登录接口存在SQL注入，参数为username，payload是' or 1=1-- -，可绕过验证”。这算合格吗？勉强。但问题在于他没写清楚环境版本、是否默认配置、请求包完整结构。我按他给的payload试了五分钟，发现他用的Python脚本里带了自定义的User-Agent，而那个版本的应用恰好对特定UA有过滤逻辑。他省了这行细节，我多花了半小时。

所以第一块内容，必须是复现步骤。别废话，直接上干货。用编号列出每一步，从打开浏览器开始。别假设对方知道你的测试工具。Burp的请求包就贴原始文本，别截图，截图没法复制。每一步之间留空格，别挤成一团。

然后是影响范围。这一块很多人写“可能导致数据泄露”，这种话等于没说。你要具体到能泄露哪张表、哪些字段、涉及多少用户量级。如果你不确定具体数据，至少说明你验证到哪一步——是只读到了版本号，还是能拖库？诚实比夸大重要。我见过一个报告写“可获取所有用户密码”，结果复现时发现只能读到加密后的hash，而且那个hash算法是bcrypt。影响描述失实，会直接拉低你的可信度。

修复建议别抄OWASP模板。你既然发现了漏洞，就该想过怎么补。哪怕给个方向也好。“建议使用参数化查询”这种话，开发看了想打人。你要写清楚：在哪个文件的哪一行，用了字符串拼接，应该改成预编译的哪种写法。如果你不清楚具体代码，就描述清楚触发点，让开发能按图索骥。

最后，附上你的环境信息。操作系统、中间件版本、数据库版本、浏览器版本、测试工具版本。这些不是可有可无的附录，而是复现的土壤。同一个漏洞，在MySQL 5.7和8.0上的表现可能完全不同。你不写，对方就得猜，猜错了就来回折腾。

格式上，别用花哨的排版。纯文本或者Markdown都行。重点内容加粗可以，但别满屏都是加粗。标题层级别超过三级，否则看着像论文。长度控制在200到800字之间，太短说不清，太长没人看。

对了，还有个小细节——提交前自己照着报告复现一遍。如果你自己都跑不通，就别指望别人能跑通。这个动作能过滤掉一半以上的垃圾报告。

写漏洞报告不是写日记，是写操作手册。你的读者是那个要熬夜修bug的可怜人。帮他省时间，就是帮你自己攒口碑。