程序说已隐藏 API Key，怎样用测试确认日志真的脱敏

程序声称隐藏了 API Key，要通过故意注入无效哨兵来验证日志。测试不使用真实凭据，分别覆盖 Header、异常堆栈和调试输出，并检查安全字段仍然保留。本文只验收日志脱敏，不讨论密钥存储、轮换或泄漏后的处理流程。

哨兵要进入真实的日志路径

下载脱敏回归夹具。脚本用固定无效字符串 DEMO_SECRET_ONLY_FOR_TEST_7 构造请求头、异常和调试对象，验证最终格式化文本中没有它。这个值没有调用能力，可以安全作为测试数据，但不要把格式测试换成真实 Key。

入口	合成载荷	检查出口
Header	Authorization与大小写变体	处理器最终文本
异常	message含哨兵，堆栈重复message	格式化后的完整异常
调试	嵌套对象与JSON字符串	实际文件或捕获输出
良性字段	状态码500、任务编号	应继续可见

如果只测试一个独立 redact() 函数，应用另一个错误处理器仍可能绕过它。因此需要将哨兵送到实际使用的 logger、handler和formatter，或者真正写入隔离日志文件后读取检查。

先证明测试能抓到泄漏

做一条负向控制：未脱敏文本必须被检测为泄漏；再让正确处理路径通过。否则测试可能根本没读到日志，或者哨兵没有进入输出却显示通过。还要断言日志不为空，状态码和诊断编号存在，避免“所有内容都删掉”伪装成功。

python n037-redaction-check.py

附件自检只证明其合成路径与检测断言工作，不证明任何真实应用已经完成脱敏。接入自己的代码时，用实际日志输出替换示例 formatter，保留负向控制。

字符串、对象与异常分开覆盖

结构化对象可以按敏感键名隐藏整个值，字符串中的凭据需要文本处理，异常堆栈则可能在首行和后续行重复原始消息。只改 message 不改 exc_info 格式化结果，仍可能泄漏。日志在不同处理器之间传播时，也要检查每个出口是否都经过处理。

加入 URL 查询串、认证方案、数组、嵌套对象和转义 JSON 等边界样本，但不要宣称一组正则覆盖所有秘密。应用可能有未知字段、二进制载荷或第三方插件日志，需按实际接入扩展。对不能安全解析的大对象，可采用白名单诊断摘要，明确舍弃内容的原因。

持续回归要绑定日志配置

升级 SDK、启用 debug、加入新传输库或修改异常处理后，重跑这组样本。应用默认级别下安全，不代表调试级别也安全。把测试入口、级别、处理器配置和输出目录写入报告，扫描最终产物，而不是只扫描源码里有没有密钥。

若发现泄漏，报告具体出口和触发形态，不把哨兵样例直接替换成线上秘密来确认。修复后同一负例应被遮蔽，良性字段仍应保留。这份双向断言比单纯搜索不到一个字符串更有诊断意义。

常见问题

扫描源代码没有密钥够吗？ 不够，运行时异常和调试对象可能带入凭据。

只遮前几位就算脱敏吗？ 应按应用安全合同处理，不能保留仍可能可用的完整凭据片段。

夹具通过说明没有未知泄漏吗？ 不能，它覆盖已定义路径，应随接入变化增加样本。

继续处理相关问题

相关入口：OpenAI API 接入基础。

官方依据与核对日期

核对日：2026-10-23。Python logging：日志由logger、handler、filter和formatter协作，需关注最终输出与传播链。文中的流程、阈值和合成数据属于工程示例，不能代替当前账号、文件或运行环境的验收。