你在后台查看访问日志时，可能会发现大量针对 /wp-json/wp/v2/users 的扫描请求，或者服务器上出现陌生的登录成功记录——登录 IP 不固定、时间集中在深夜，而站内明明只有你一个管理员。这类问题的共同来源是 WordPress REST API 的默认暴露面：接口对所有访客开放，任何一个拥有有效凭据的客户端都能携带凭据调用全部能力。本文教你如何从三步入手完成 WordPress REST API 安全加固：用应用密码替代主密码收敛权限、限制接口暴露范围、建立可回溯的访问审计，帮你把接口风险降到可控范围。
先弄清 REST API 暴露了什么
REST API（表述性状态传递接口）是 WordPress 从 4.7 版本开始内置的机器访问接口，位于 /wp-json/ 路径下。插件更新、区块编辑器自动保存、移动端 App 发布文章，走的都是这套接口。问题在于它的默认设计面向”可用”而非”最小暴露”：未认证访客可以匿名读取文章列表、页面结构，部分配置不当的站点还会暴露用户枚举接口，攻击者访问 /wp-json/wp/v2/users 就能拿到合法用户名清单，再对着登录接口做密码猜测。
密码体系的问题更隐蔽。站点管理员的主密码一旦在某个插件或脚本里被明文使用——比如某个自动发文工具配置里填了管理员账号——这个万能凭据就同时拥有后台登录、XML-RPC、REST API 全部能力，泄露后的影响面无法收窄。2023 年以来主流插件生态大量接入的”应用密码”机制正是针对这个问题：它是 WordPress 5.6 起内置的独立凭据，每个应用密码只对应一个用途，可以单独生成、单独撤销，而主密码本身不需要参与机器调用。后续章节会按”先换凭据、再收接口、最后建审计”的顺序展开具体操作。
第一步：用应用密码收敛权限
应用密码的入口在后台「用户 → 个人资料」页面底部，勾选后输入一个用途名称（比如”自动发文脚本”）就能生成一串 24 位密码。它的核心价值是权限隔离：每个应用密码只绑定一个用途，脚本泄露时撤销对应密码即可，不需要修改主密码，也不会影响其他正在运行的集成。
操作时按下面的顺序执行，可以把切换风险控制在最低：
- 先在「用户 → 个人资料」生成一个新的应用密码，用途名称写清楚对应脚本或插件，方便后续审计对号入座。
- 把站内所有定时发布、自动备份、移动端 App 里的”账号+主密码”配置逐个替换为”账号+应用密码”，替换一个验证一个，确认任务正常执行再处理下一个。
- 全部替换完成后，在数据库层面确认主密码不再被任何脚本引用：用
grep -r "wp_password" /home/你的脚本目录/之类的搜索排查服务器上的配置文件残留。 - 撤销不再使用的旧应用密码。每撤销一个，观察一天相关任务日志，确认没有业务依赖后再撤销下一个。
一个容易被忽略的细节：应用密码默认具备该用户的全部权限，管理员账号生成的应用密码同样是管理员级。所以给脚本用的应用密码应该尽量来自低权限专用账号——比如只保留”编辑文章”权限的作者账号——而不是直接用管理员账号生成。Hostease 的 WordPress 主机用户可以在主机面板的文件管理器里直接查看和编辑这类配置文件，排查脚本残留时不需要额外登录 SSH。
第二步：限制接口暴露范围
凭据收敛之后，第二步是收窄 REST API 本身的暴露面。默认状态下，未认证访客能匿名访问的接口比多数站长预期的多，下面这段代码把用户枚举接口和 XML-RPC 一起关掉，把代码加入当前主题的 functions.php 或站点专用插件即可：
// 关闭未认证的用户枚举接口
add_filter( 'rest_endpoints', function( $endpoints ) {
if ( ! is_user_logged_in() ) {
foreach ( array( '/wp/v2/users', '/wp/v2/users/(?P<id>[\d]+)' ) as $route ) {
if ( isset( $endpoints[ $route ] ) ) {
unset( $endpoints[ $route ] );
}
}
}
return $endpoints;
} );
// 彻底禁用 XML-RPC，减少一份暴露面
add_filter( 'xmlrpc_enabled', '__return_false' );
保存后在浏览器访问 https://你的域名/wp-json/wp/v2/users，未登录状态应返回 401 或 404，说明用户枚举已经关闭。注意评估业务影响后再动手：如果你的站点正在运行依赖用户数据的第三方集成（比如某个会员系统），关掉用户接口可能导致它读取失败，上线前先在测试环境验证一遍。对完整站点安全策略而言，这一步只是接口层的一环，可以结合之前写过的 WordPress 安全加固指南 一起规划，把登录保护、文件权限、接口收敛串成完整链路。
第三步：建立访问审计与持续监控
权限收敛和接口收窄解决的是”攻击面”，审计解决的是”可见性”——没有记录，一次成功的密码猜测可能几个月都不会被发现。审计要覆盖三个层次：谁在调用、调用了什么、结果是否异常。
第一层是服务器访问日志。REST API 的调用在 Nginx 或 Apache 的 access log 里表现为大量 POST /wp-json/... 请求，用一条命令就能统计出调用最频繁的来源 IP：
grep "POST /wp-json" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -10
如果某个 IP 的调用量远超正常插件水平——比如一天几千次而站内只有两个自动化任务——就值得进一步核查这个来源的用途。
第二层是 WordPress 侧的认证失败记录。应用密码的认证失败和普通登录失败一样会触发 wp_authenticate 流程，可以安装一款审计类插件（如 WP Activity Log 或 Simple History）记录每次认证事件，重点关注”同一账号短时间多次认证失败”和”陌生 IP 认证成功”两类事件。设置插件邮件告警阈值时，建议按每小时失败次数触发，而不是每天，缩短从发生到发现的窗口。
第三层是定期复核凭据清单。每月在「用户 → 个人资料 → 应用密码」页面检查一次所有应用密码的最近使用时间，超过 30 天未使用的直接撤销。配合服务器层面的定期巡检——比如之前讲过的 服务器性能监控实践 中提到的日志巡检习惯——把凭据复核纳入固定的运维节奏，而不是出了问题才回头翻日志。
常见误区与验证方法
加固落地后，有几个常见误区需要主动验证，避免留下假象的安全感。
第一个误区是只改代码不验证。上面的 PHP 过滤器加进去后，如果主题更新覆盖了 functions.php，改动会静默消失。建议把这类代码放进站点专用插件（mu-plugins 目录下的独立文件），或者每次主题更新后用 curl -s -o /dev/null -w "%{http_code}" https://你的域名/wp-json/wp/v2/users 复测返回码，确认仍是 401/404。
第二个误区是给应用密码授予过高权限。管理员账号的应用密码一旦泄露，攻击者可以直接通过 REST API 发布内容、修改插件，绕过登录界面的所有限制。正确做法是建立”脚本专用低权限账号”，按最小权限原则分配角色，应用密码永远绑定在这个账号上。
第三个误区是把 REST API 整个禁用就以为万事大吉。直接关闭全部 REST API 会破坏区块编辑器的自动保存、计划发布和大量插件功能，属于”为了安全牺牲可用”的过度加固。更平衡的做法是保留已认证访问、只收窄匿名接口，配合 CDN（内容分发网络）层的请求频率限制缓解扫描压力。
验证加固效果的完整检查清单：
- 未登录访问用户枚举接口返回 401 或 404，而不是用户名列表
- 所有自动化任务改用应用密码后连续运行 3 天无认证失败
- 服务器日志中不再出现针对 xmlrpc.php 的大批量 POST 请求
- 审计插件能正常记录认证成功与失败事件，告警阈值已生效
- 应用密码清单中不存在超过 30 天未使用的条目
总结与行动建议
REST API 暴露面、主密码滥用、缺乏审计记录，是 WordPress 接口被扫描和滥用的三个根源。对应的三步加固——应用密码收敛凭据、收窄接口暴露范围、建立三层审计——全部可以在一台普通 VPS（虚拟专用服务器）上完成，不需要额外采购设备，一个下午就能落地。
如果你需要一套开箱即用的运行环境来承载这些加固措施，可以考虑 Hostease 的 WordPress 主机方案，环境预配置、面板可直接管理文件与日志，减少了自行排查服务器配置的时间成本；已有独立服务器的用户，也可以参考 VPS 主机方案 获取完整的 root 权限自行实施。建议的落地顺序是：本周先生成应用密码并完成脚本切换，下周关掉匿名用户枚举接口并部署审计插件，月底前把凭据复核纳入月度巡检清单。安全加固不是一次性的动作，把这三步固化成例行动作，才能让接口风险长期处于可控范围。