WordPress 7.2 秘密密钥 API 提案：原生加密凭证存储终于要来了
WordPress 长期存在一个安全隐患：插件若需调用 API 密钥，只能以明文形式写入 options 数据表。这些明文凭证会随数据库备份、暂存环境克隆等途径扩散泄露。针对这一架构性缺陷，贡献者 Eric Mann 在 Make WordPress Core 博客发布了一份 Secrets API 提案，计划在 WordPress 7.2 中引入首个原生加密凭证存储方案。
现状：插件各自为战，明文存储成顽疾
据 Mann 介绍，他六个月前在与 Two Factor 插件开发者讨论令牌加密时动手制作了概念验证插件，并主动请缨在 7.2 周期内完成实现工作。
目前 WordPress 没有任何「密钥」概念，所有插件只能把 API 密钥明文写入 options 表——因为这是唯一可用的存储方式。Google Site Kit、WooCommerce 支付网关等主流插件多年来自行实现了加密，但彼此标准不统一，没有形成社区共识。
「过去一个普通网站顶多存放一个 Mailchimp 密钥和一个 reCAPTCHA 密钥，出了问题也能承受。」Mann 在提案中写道，「但 AI 服务集成让凭证数量激增、泄露代价也高得多——模型提供商 API 密钥一旦泄露，就是按量计费的财务漏洞。爆炸半径扩大了，存储机制却原地踏步。」
今年 5 月 WordPress 7.0 推出 AI Connectors 页面后，明文 API 密钥的安全问题引发社区热议。WordPress 安全团队代表 John Blackbourn 随后在 Trac 上标记了这一架构性缺口。
核心设计：三个函数、强制加密、可插拔后端
Mann 提出的方案是一套小型核心函数集：
wp_set_secret()— 写入加密凭证wp_get_secret()— 读取解密凭证wp_delete_secret()— 删除凭证
加密层默认启用且无法关闭。Mann 强调：「如果一个 API 可以被配置为存储明文，那它就是一个名字误导人的 Options API。」 默认情况下，加密后的密文存储在现有 options 表中，但主机可通过 drop-in 替换存储后端或密钥管理系统。API 还将赋予站点所有者查询能力：站点上存在哪些凭证、哪些代码在调用它们、上次轮换是什么时候。
能力边界与已知限制
Mann 明确划定了 7.2 的范围：仅实现存储层，暂不包含管理后台。他表示先要把读写语义理顺，7.3 再做设置界面。WP-CLI 支持则会从第一天就内置，确保 API 有第一个官方消费者。
对于安全边界，Mann 坦承任何运行在 WordPress 进程内的代码都能调用 wp_get_secret()，因此该 API 无法防御代码执行攻击——这是 Patchstack CEO Oliver Sild 在今年 5 月提出的质疑。但 Mann 认为更常见的泄露场景是数据库被盗，而非代码执行。
社区反馈：积极为主，质疑集中在多租户场景
提案放出后社区反馈整体积极。WordPress VIP 工程师 Jake Spurlock（提案推手之一）在 X 上表示，随着 WordPress 社区深入 AI 代理工作流，这个 API 正是刚需。
GravityKit 创始人 Zack Katz 在 Post Status Slack 直言提案「早该来了」——他长期受困于安全插件自动轮换 WordPress salts 时导致许可证密钥失效的老问题。
开发者 emrl 表示团队此前独立用 defuse/php-encryption 库实现了相同功能，称提案「非常出色」。
最具实质性的设计质疑来自 Pantheon 高级开发者倡导者 Chris Reynolds。他指出许多主机采用外部密钥存储，读写路径与 WordPress 应用层分离：
「我们的密钥对应用层只读，写操作走 CLI 工具 Terminus 或仪表盘。」Reynolds 解释道，「当前 API 设计无法表达『某个存储后端只读不可写』这一状态。另外平台级存储本身已处理加密，API 的强制加密层会造成双重加密，让密钥在 WordPress 之外变成不可解读的黑箱。」
Mann 已计划先发布功能插件，供贡献者在进入核心前充分测试。他正在征集反馈，Trac 补丁预计 9 月底出炉。
时间线与质量优先原则
WordPress 7.2 测试阶段定于 10 月 20–22 日启动。Mann 明确表示，如果 API 届时未准备就绪，宁可推迟到 7.3，也不愿仓促合入。
