WordPress 支撑着大约 43% 的网络。这个统计数据经常被引用为该平台成功的证据。它同样可以用来解释为什么 WordPress 网站成为互联网上最常被攻击的目标之一。当单一平台占据了近半数的所有网站时，大规模利用它就变得经济合理。自动化扫描器全天候探测已知的错误配置。问题不在于你的 WordPress 网站是否会被针对——它会的——而在于你运行的配置是否让利用变得轻而易举还是真正困难。大多数默认安装都明确属于前者。WordPress 安全错误配置修复不是一次性任务；它是一种持续的姿态。以下是这种姿态的实际样子。
默认安装并不安全
一个原生的 WordPress 安装附带的是为易用性而非防御优化的设置。这是一种有意的权衡——WordPress 服务着数百万的普通用户，他们甚至不知道 XML-RPC 是什么，更不用说它为何构成了攻击面。问题在于开发者和网站运营者在部署 WordPress 时没有从安全角度重新审视这些默认设置。其中一些默认设置在生产环境中实际上是有害的。
在许多伴随 WordPress 安装的网络服务器配置中，目录列表默认是启用的。如果你的 .htaccess 或 Nginx 等效文件中没有 Options -Indexes 指令，在浏览器中访问类似 /wp-content/uploads/2024/ 的路径可能会返回该目录中所有文件的完整列表。对于进行侦察的攻击者来说，这是关于你的文件结构、插件版本和上传资源的免费情报。
调试模式是类似的情况。WP_DEBUG 默认为 false，但在无数生产站点中被启用，因为开发者在故障排除期间打开了它，却从未关闭。当 WP_DEBUG_DISPLAY 设置为 true 时，PHP 错误——包括文件路径、数据库查询和配置细节——会直接打印到页面上。这不是理论上的担忧；这是攻击者可以用来识别可利用插件并了解你服务器布局的信息。
这些不是异乎寻常的攻击向量。它们是 Shodan、WPScan 和自动化利用工具包首先检查的基本错误配置类型。
登录面问题
WordPress 的管理登录页面位于 /wp-login.php，而这条路径已被所有现有的自动化扫描器所熟知。机器人会持续使用凭据列表对该端点进行循环尝试。这个可预测性比大多数管理员意识到的更为重要：如果攻击者确切知道发送请求的位置，那么唯一的不确定因素就是他们是否能够通过身份验证。任何拥有弱密码或重复使用密码的管理员账户，只需一次凭据泄露就可能完全被攻破。
标准的应对措施是移动或限制登录页面。像 WPS Hide Login 这样的插件允许您将登录 URL 更改为任意路径，这能显著减少对该端点的自动化流量。这不带贬义意义上的”通过模糊性实现的安全”——它是一种阻力，而阻力对抵御自动化攻击具有实际价值。将其与速率限制（如 Limit Login Attempts Reloaded 插件，或通过 Nginx 的 limit_req_zone 指令实现的服务器级速率限制）结合使用，您可以消除大多数暴力破解风险。
双因素认证应该无条件地包含在这个安全体系中。WP 2FA 和 Google Authenticator 插件都支持基于 TOTP 的管理员账户双因素认证。考虑到凭证填充是跨网络应用程序最主要的初始访问方式，双因素认证是投资回报率最高的单一控制措施。拥有有效密码的攻击者没有第二因素就无法登录。这完全打破了最常见的攻击链。
一个令人尴尬地普遍存在的配置失误：默认管理员用户名。WordPress 历史上默认使用 “admin” 作为用户名，仍有相当一部分站点在使用它。凭据列表总是将 “admin” 作为顶级候选目标。如果您的管理员账户用户名是 “admin”，请更改它。最干净的方法是创建一个具有不同用户名的新管理员账户，将所有内容重新分配给它，然后删除原始账户。一些管理员使用 WP-CLI 命令 wp user update 1 --user_login=newusername，尽管这之后需要直接进行数据库一致性检查。
XML-RPC：应该被禁用的遗留接口
XML-RPC 是在 REST API 出现之前 WordPress 的远程发布 API。它允许像 MarsEdit 这样的工具和移动应用程序在不使用浏览器管理面板的情况下发布内容。如今，REST API 更简洁地处理了这些用例。XML-RPC 大多已无必要，但它仍然是默认启用的。
XML-RPC 的安全问题不仅仅是凭据暴力破解，尽管这确实存在：XML-RPC 支持 system.multicall 方法，允许在单个 HTTP 请求中进行多次方法调用，这意味着攻击者可以在单个请求中测试数百个用户名-密码组合，有效地绕过了简单的每请求速率限制。DDoS 放大向量也值得注意 — 启用了 XML-RPC 的 WordPress 站点已被用作针对第三方目标的 pingback 洪水攻击中的不知情参与者。
除非你有特定且经过验证的需要使用 XML-RPC（传统的移动发布工作流、某些配置中的 Jetpack），否则请禁用它。最可靠的方法是在服务器级别进行阻止，而不是使用插件 — 插件可以被禁用，但服务器规则无法被被入侵的管理员账户撤销：
对于 Apache，在
.htaccess文件中的Files xmlrpc.php块内添加Deny from all。对于 Nginx，在服务器块中添加location = /xmlrpc.php { deny all; }。这可以在 WordPress 甚至加载之前就阻止端点，除了减少攻击面外，还节省了处理开销。
插件漏洞：实际的攻击面
Sucuri 的年度被黑网站报告 consistently 将大约 90% 的 WordPress 漏洞归因于有漏洞的插件和主题，而不是 WordPress 核心。这个数字很重要：在运行过时插件的同时加固 WordPress 核心，就像加固保险库门却留下窗户开着一样。
插件漏洞生命周期是可预测的。研究人员或攻击者发现流行插件中的漏洞 — 跨站脚本、SQL 注入、任意文件上传、未认证的权限提升。如果提交了 CVE 并发布了补丁，补丁会被公开索引。自动化扫描器几乎立即开始探测易受攻击的版本。在补丁发布后 48-72 小时内未更新的站点面临更高的风险，因为该漏洞现已公开。
WPScan 漏洞数据库和 Patchstack 都跟踪插件 CVE。运行 wpscan --url yoursite.com --api-token YOUR_TOKEN 将枚举已安装的插件，并标记任何与已安装版本存在已知 CVE 的插件。这是最低限度的可行外部审计 — 定期进行，而不仅仅是一次。WPScan 的免费 API 层每天允许 25 次 API 请求，足以对小型组合进行常规扫描。
减少插件攻击面的具体措施：
- 删除未使用的插件，而不仅仅是停用它们。 已停用的插件仍然存在于文件系统中，可能成为文件包含攻击的目标。
- 为无需在更新前测试的插件启用自动更新。 对于运行自定义集成的生产站点，设置一个暂存环境，您可以在其中验证更新后再部署。未经审查的更新破坏功能的风险几乎总是低于停留在易受攻击版本的风险。
- 审核插件的年龄和维护状态。 最后更新时间为两年前且没有积极开发的插件是一个隐患。检查 WordPress 插件存储库 — 它会显示插件最后更新的时间以及是否已针对最近的 WordPress 版本进行测试。被弃用的插件经常成为目标，因为它们的漏洞永远不会被修补。
- 对运行的插件数量要严格。 每个插件都是一个潜在的安全漏洞。运行 40 个插件的站点的攻击面明显大于运行 15 个插件的站点。评估每个插件是否真正必要，或者其功能是否可以通过代码处理。
wp-config.php 安全加固：检查清单
wp-config.php 是 WordPress 安装中最敏感的文件。它包含数据库凭据、安全密钥和从根本上影响站点安全态势的配置开关。正确设置它需要的不仅仅是设置一个强数据库密码。
安全密钥和盐值。 WordPress 使用这些常量来哈希密码和会话令牌。全新安装中的默认值只是占位符。在 api.wordpress.org/secret-key/1.1/salt/ 生成适当的值，并将它们粘贴到您的配置中。如果您有理由相信您的站点已被入侵并希望使所有活动会话失效，重新生成这些盐值将强制每个登录用户重新认证。
在生产环境中关闭调试模式。 这应该在您的配置中明确：define( 'WP_DEBUG', false );。如果您需要记录错误而不显示它们，请使用 define( 'WP_DEBUG_LOG', true ); 和 define( 'WP_DEBUG_DISPLAY', false );，并确保日志文件位于 Web 根目录之外，或通过您的 Web 服务器配置进行访问限制。
更改表前缀。 默认的 wp_ 前缀是众所周知的。SQL 注入攻击通常会按名称引用它。将其更改为类似 site4k2_ 的内容并不能防止 SQL 注入——这需要在代码中使用参数化查询——但它提高了成功通用攻击所需的特定性。对于现有站点，更改前缀需要进行数据库迁移；像 WP-CLI 的 wp search-replace 这样的工具可以帮助，但首先应在暂存副本上进行彻底测试。
从管理面板禁用文件编辑。 WordPress 附带一个主题和插件编辑器，可通过管理仪表板访问。如果攻击者获取了管理员凭据，此编辑器将提供即时的任意 PHP 执行能力。在生产环境中没有理由启用它：define( 'DISALLOW_FILE_EDIT', true );。如果您想完全防止从管理面板安装插件和主题——适用于通过部署管道而非 WordPress 仪表板管理更新的站点——可以将其与 define( 'DISALLOW_FILE_MODS', true ); 配合使用。
将 wp-config.php 移到 Web 根目录上方。 如果在 Web 根目录中找不到 wp-config.php，WordPress 将会在安装路径上方一个目录中查找它。将其移动到那里意味着配置错误的 PHP 解析器——将 PHP 文件作为纯文本提供——无法通过 HTTP 直接暴露您的数据库凭据。这是一种纵深防御措施，不是主要控制手段，但成本为零且收益真实。
文件权限：777 问题
在 WordPress 文件或目录上设置为 777（全局可写）的权限是教程领域的一个持续问题。”如果遇到权限错误，请 chmod 777″ 的说明出现在大量 WordPress 指南和 Stack Overflow 答案中。它通过移除所有访问控制来解决即时问题，而这恰恰是错误的权衡。
在典型的共享主机或 VPS 主机上的 WordPress 安装的正确权限：
| 目标 | 正确权限 | 理由 |
|---|---|---|
WordPress 文件（.php 等） |
644 | 所有者读写，全局只读 |
| WordPress 目录 | 755 | 所有者完全控制，组/全局遍历和读取 |
wp-config.php |
600 或 640 | 无全局读取权限；仅所有者（以及需要的组） |
wp-content/uploads |
755 | Web 服务器需要写入权限用于上传；永远不要设为 777 |
上传目录是大多数权限混乱的根源所在。Web 服务器进程需要写入上传的文件。解决方案不是使用 777 权限，而是确保上传目录由 Web 服务器用户（在 Debian/Ubuntu 系统上是 www-data）拥有或可写入。使用 chown -R www-data:www-data wp-content/uploads 并设置 755 权限可以干净利落地实现这一点。
此外，上传目录中不应有任何 PHP 文件可被 Web 服务器执行。恶意上传的带有 .php 扩展名的文件不应可被解释为代码。将此添加到您上传目录内的 .htaccess 文件中：php_flag engine off（Apache）或 Nginx 的等效配置 location ~* .php$ { deny all; }，作用域限定在上传路径。
安全头：大多数 WordPress 站点所缺失的部分
HTTP 安全头是服务器级别的指令，告诉浏览器如何处理网站内容。它们并非 WordPress 特有的，但在大多数 WordPress 部署中系统性地缺失。没有适当安全头的网站容易受到各类客户端攻击，而这些攻击本可以通过安全头预防。
值得实施的安全头，按影响程度排序：
- 内容安全策略 (CSP)。 定义浏览器应该信任哪些来源的脚本、样式、图像和其他资源。正确配置的 CSP 可以防止绝大多数 XSS 攻击得逞——即使恶意 JavaScript 被注入，也无法从未授权来源加载或泄露数据。CSP 是最难正确配置的头部，因为 WordPress 的插件生态系统广泛使用内联脚本。一个合理的起点是仅报告策略（
Content-Security-Policy-Report-Only），在强制执行前识别违规情况。 - X-Frame-Options: SAMEORIGIN。 防止您的站点被嵌入到其他域的 iframe 中。这可以阻止点击劫持攻击，攻击者会使用透明元素覆盖您的登录页面来窃取凭据。现代等效方案是
Content-Security-Policy: frame-ancestors 'self'，但 X-Frame-Options 仍然需要用于支持旧版浏览器。 - X-Content-Type-Options: nosniff。 防止浏览器对偏离声明内容类型的响应进行 MIME 探测。没有这个设置，浏览器可能会将上传的文件作为 JavaScript 执行，即使它是以非脚本内容类型提供的。
- 严格传输安全 (HSTS)。 一旦您运行 HTTPS（您应该这样做——Let’s Encrypt 使其免费且自动化），HSTS 指示浏览器完全拒绝您域的 HTTP 连接。典型起始值：
max-age=31536000; includeSubDomains。在确信您的整个域和子域名都可靠地使用 HTTPS 之前，不要添加preload。 - Referrer-Policy: strict-origin-when-cross-origin。 控制导航到外部站点时包含多少引荐信息。默认的浏览器行为可能会将管理 URL 和会话相关查询参数泄露给第三方分析工具。
- 权限策略 (Permissions-Policy)。 限制对浏览器 API（如摄像头、麦克风和地理位置）的访问。对于大多数 WordPress 站点，这些功能是不必要的，应该被明确阻止：
Permissions-Policy: camera=(), microphone=(), geolocation=()。
securityheaders.com 扫描器会对您当前的头部配置进行评分并解释每个缺失的头部。在实施这些更改之前和之后，针对您的站点运行它。低于 B 的分数表示有意义且可修复的漏洞。
备份策略：”拥有备份”的实际含义
每个 WordPress 运营商都会告诉您他们有备份。其中相当一部分人会在最糟糕的时刻发现，他们的备份不完整、未经测试、无法访问，或者与被攻陷的服务器位于同一位置。您无法在合理时间内恢复的备份不是真正的备份——它只是备份的假象。
一个有效的备份策略需要四个特性协同工作：
自动化。 在压力下手动备份无法保持一致性。使用无需人工干预即可按计划运行的解决方案。UpdraftPlus、WP Time Capsule 和 BackWPup 是成熟的插件；对于托管主机，Kinsta 和 WP Engine 包含自动每日备份。备份频率应与您的内容更新节奏相匹配—每天发布十篇文章的网站需要的备份计划与静态宣传册网站不同。
异地存储。 如果服务器被攻破或托管账户被删除，存储在与 WordPress 安装在同一服务器上的备份将毫无价值。配置您的备份工具将副本推送到独立的目的地：Amazon S3、Backblaze B2 或 Google Drive。Backblaze B2 的成本约为每月每 GB 0.006 美元—对于一个 10 GB 的网站备份集，真正的异地冗余成本为每月 0.06 美元。将备份保存在同一服务器上的成本论点是不成立的。
已测试的恢复。 备份是关于危机中会发生什么的假设。测试这个假设。至少每季度一次：下载一个备份，启动一个暂存环境，并从中恢复。验证网站是否正确加载，数据库内容是否完整，以及恢复过程是否在可接受的时间内完成。在事件发生时发现您的备份文件已损坏、恢复程序没有文档记录，或完整恢复需要 14 小时，这些都是不可接受的结果。
保留深度。 保留 7 天的单个每日备份对于复杂攻击来说是不够的。某些漏洞—特别是数据库注入和恶意软件植入—不会立即被发现。恶意代码可能在有人注意到之前已经存在了 30 天。您的备份保留需要回溯到足够远的时间以到达一个干净的状态。至少保留 30 天的备份；任何处理敏感用户数据的网站应保留 90 天的备份。
安全插件：有用，但不充分
Wordfence 和 Sucuri 是主要的 WordPress 安全插件。两者都确实有用。但它们都不能替代本文所述的配置工作，将它们视为替代品是一个常见且代价高昂的错误。
Wordfence 的 Web 应用防火墙 (WAF) 在 WordPress PHP 上下文中运行，这意味着它在 WordPress 已经加载后才运行。服务器级别的漏洞或 PHP 执行绕过可以在 Wordfence 对其有任何可见性之前就攻破系统。这并非 Wordfence 独有的问题—任何在应用层运行的安全插件都存在这种架构限制。Sucuri 的基于云的 WAF（在流量到达您的服务器之前通过 Sucuri 的网络路由所有流量）没有此限制，但它是一项付费功能，并引入了对 DNS 的依赖。
Wordfence 的优势：针对 WordPress 核心和插件仓库的文件完整性监控、恶意软件扫描、对 wp-login.php 的暴力破解防护，以及对意外文件变更的警报。这些功能都很有价值。特别是文件完整性监控能够捕获其他监控方式会遗漏的入侵情况——例如，注入到主题文件中的后门会显示为已知文件中的意外修改。
正确的思维模式：安全插件负责检测和一些表层拦截。配置加固——服务器权限、头部、wp-config.php 设置、禁用 XML-RPC——处理插件无法触及的层面的预防。你需要两者兼备，而不是用一个替代另一个。
监控：需要注意什么
安全不是你实现后就能被动维持的状态。有效的 WordPress 安全需要持续观察。三类监控能为投入的努力提供最多的信号。
文件完整性监控。 跟踪 PHP 文件、.htaccess 和配置文件的变更。Wordfence 在插件级别执行此操作；在服务器端，对于较小的设置，像 AIDE（高级入侵检测环境）这样的工具或简单的由 cron 驱动的与已知良好基线的 md5sum 比较都能工作。任何不是通过更新 initiated 的核心 WordPress 文件的修改都是严重入侵指标。
登录失败警报。 针对 /wp-login.php 或 /wp-json/ 端点的登录失败突然激增表明存在活跃的暴力破解活动。你的服务器访问日志和 Wordfence 的登录安全模块都会显示这一点。应触发警报的阈值因网站而异，但认证失败数量数量级的增加总是值得调查。
管理员用户审计。 定期验证具有管理员权限的用户列表。后门安装经常创建一个用户名不显眼的新管理员账户。通过 WP-CLI 执行类似 wp user list --role=administrator 的查询，或直接对 wp_usermeta 中的 wp_capabilities 字段进行数据库查询，可以显示任何未授权的管理员账户。如果你发现了一个你没有创建的账户，你就存在活跃入侵——优先事项事件响应，而不是进一步加固。
自动化监控减少了维持可接受可见性所需的人工关注。像 ManageWP 和 MainWP 这样的服务聚合多个 WordPress 站点的监控，在单一仪表板中显示更新需求、正常运行时间警报和安全扫描结果。对于管理网站组合的机构或开发人员来说，开销减少是显著的。
从哪里开始
WordPress安全加固的全部范围可能会让人感到无所适从，特别是对于管理多个站点或继承具有未知配置历史记录的现有安装的操作员而言。实际的优先级安排如下。
在最初的24小时内：在服务器级别禁用XML-RPC，将WP_DEBUG设置为false，阻止目录列表，将所有插件更新到当前版本，并在所有管理员账户上启用双因素认证(2FA)。这五个措施以最简单的实施复杂度解决了最高概率的攻击向量。
在第一周内：使用正确的调试设置、重新生成的盐值和禁用文件编辑来加固wp-config.php。在整个安装中设置正确的文件权限。实施安全头文件——即使只包含X-Frame-Options、X-Content-Type-Options和HSTS的部分集合，也比完全没有要好得多。设置经过测试恢复流程的异地自动备份。
持续进行：定期对您的安装运行WPScan。每季度审核插件列表并移除未在积极使用的插件。在任何事件或重大人员变动后审核管理员用户列表。监控文件完整性和身份验证日志中的异常情况。
针对WordPress的威胁形势并非一成不变。新的漏洞不断被披露。那些未被攻破的网站并不是那些仅完成一次加固清单的网站——而是那些将安全视为持续运营纪律而非有完成日期项目的网站。这种心态的转变，比任何单独的配置更改都更能成为可防御WordPress部署的真正基础。