安全意识、故障复盘与文档：让系统经得起真实使用
收藏列表刚上线，你用第二个账号测试，发现改一下请求里的用户 ID 就能读到别人的记录。这不是界面的小瑕疵，而是系统没有守住承诺。软件质量不仅是正常路径能跑通，也包括不该发生的事被阻止，以及失败后团队知道怎样恢复。
1. 从“谁能对什么做什么”开始
先列出身份、对象和动作：匿名用户能阅读公开文章；登录读者能管理自己的收藏；管理员能维护文章。身份确认通常称为认证；决定某个身份能执行哪些动作称为授权。登录成功不代表拥有全部权限。
这些规则必须在服务端或可信的数据访问层执行。浏览器里的按钮和请求参数由用户控制，隐藏管理入口不能防止别人直接请求接口。查询收藏时应依据已验证身份限定范围，不能无条件相信请求提供的用户 ID。
2. 把威胁想成具体的误用场景
不要先背攻击名称，先问：“如果有人修改参数、重复请求、提交超长文本，会发生什么？”对每个重要边界，说明输入来自谁、是否可信、失败会伤害什么。
例如一篇文章标题含有 HTML 标签，页面是否把它当代码执行？这与输出方式有关，不能只在输入时删几个字符就认为安全。数据库查询应使用适当的参数化方式；权限检查、输入约束和输出处理解决不同问题，不能互相代替。
对于依赖更新，先确认公告是否涉及正在使用的版本和调用路径，再安排升级和验证。依赖扫描提供线索，但一个总分或数量并不能独自说明实际影响，也不能证明没有风险。
3. 发生故障时先保护用户
先确认影响范围和是否仍在扩大，必要时关闭有问题的入口或撤回不兼容版本。保留时间线、请求标识和关键日志，不要为了“清理现场”把定位线索删掉。
恢复服务与彻底查明原因可以是不同阶段。紧急处理时减少无关修改，并明确谁负责协调、谁查数据、谁验证恢复。小团队也需要有一个清楚的下一步，避免几个人同时修改同一处却不知道彼此在做什么。
4. 复盘要产生改进动作
复盘可以记录影响、发现方式、时间线、促成因素、恢复方法和后续行动。例如：“列表查询缺少用户范围过滤；评审没有跨账号用例；监控只看 HTTP 成功率。”这比写“开发者不细心”更能指导改进。
不责备个人并不意味着没有责任。行动项要有负责人、期限和验收方式，例如新增跨账号回归测试，并确认去掉过滤条件时测试会失败。一次故障往往有多个促成因素，不要强行只选一个“根因”来结束讨论。
5. 留下能在压力下使用的运行手册
手册应回答：如何确认当前版本，怎样查看相关日志，怎样关闭收藏入口，谁有恢复权限，恢复后检查哪些操作。命令和链接应指向当前系统，并说明执行前提。
不要把生产密码写在手册里。记录受控凭据的获取方式即可。备份存在也不等于能够恢复，应该在隔离环境试过恢复过程，并记下耗时和数据时间范围。
6. 文档面向不同读者
使用说明解释怎样完成用户任务；开发说明解释怎样运行和修改项目；接口说明约定输入输出；运行手册处理线上问题。一本混合所有细节的长文不一定好用。按读者要完成的动作组织，再用链接连接，会更容易维护。
练习与参考答案
“接口返回 200，所以用户没有受影响”是否成立？不成立。返回成功也可能包含错误数据、越权数据或误导状态。验收与监控要尽量贴近真实任务结果，并把安全边界纳入检查。