WP-JSON 接口被注入攻击这件事，最近确实让不少企业的安全团队头疼。问题不只在于修一个漏洞，而是管理层开始思考一个更大的决定：要不要对所有 API 上签名校验。
攻击暴露的不只是技术问题
WP-JSON 接口被攻击的直接原因，是部分接口对输入数据过滤不严。但更深层的问题是：企业在开放 API 的时候，功能和对接效率优先，安全校验往往被当成可选项。在内部系统、合作伙伴对接或移动端调用的场景里，不少接口只靠 IP 白名单或简单 Token，严重的甚至没有任何身份校验，默认信任调用方。
这种做法在业务小、暴露面少的阶段问题不大。但系统复杂度上来、第三方集成多了之后，攻击面会快速扩大。一个接口被攻破，攻击者可能顺着调用链探测其他接口，形成连锁风险。这次 WP-JSON 的攻击发生在 WordPress 技术栈上，但它给管理层的提醒是：整体 API 防御体系有没有类似的薄弱环节。
签名校验能做什么
签名校验的核心逻辑很清楚：每次 API 调用都带一个用密钥生成的签名，服务端验证通过才放行。攻击者就算截获了请求，没有密钥也构造不出合法调用。这个方案在金融支付、开放平台这类高安全要求的场景已经用得很成熟了。
但代价也不小。密钥的生成、存储、轮换、权限控制，这些都需要运维团队持续管理。如果系统中存在大量历史接口或第三方对接，改造过程涉及多方协调，通知合作伙伴更新调用方式、为旧系统提供兼容方案，推进周期很难精确预估。还有处理时间的问题。签名计算和验证会引入额外开销，高并发场景下可能需要优化验证逻辑或调整服务器配置。
兼容性是个常被低估的问题
企业在推行签名校验时，最常遇到的不是技术问题，而是兼容性问题。内部系统调用失败、移动端版本不兼容、第三方合作方拒绝配合，这些情况比想象中常见。如果缺乏分阶段实施计划或应急预案，可能导致业务中断或用户体验下降。
有个常见误区：认为签名校验上了就能解决所有 API 安全问题。实际上它只是防御手段之一，不能替代输入验证、权限控制等其他基础安全工作。
值不值得推，看企业情况
如果企业所在行业合规要求高，或者已经因安全事件吃过亏，签名校验的必要性是清晰的。但如果当前主要精力在业务增长、功能迭代或成本控制，把有限技术资源投入全面 API 改造，可能会拖慢其他优先级更高的项目。
签名校验不是唯一选择。强化输入验证、完善权限控制、部署 WAF、或针对高风险接口优先加固，这些措施实施难度更低、见效更快，适合作为过渡方案或与签名校验并行推进。
管理层真正要判断的是：企业当前处于什么阶段，对 API 的整体梳理做到什么程度了。如果系统已经比较完善，团队有成熟经验，全面推签名校验是对现有能力的自然延伸。但如果还在快速扩张期，技术资源紧张，API 梳理还没做完整，贸然启动全面改造可能带来超出预期的复杂度。