WordPress 安全加固：保护网站与身份的逐步指南

审阅日期：2026 年 9 月 27 日

WordPress 账户安全并非单一设置，而是一连串关于谁可登录、你暴露哪些软件、以及如何恢复的决定。官方 WordPress 加固指南把安全定义为“降低风险”而非“消除风险”，这才是合理预期。本文先说明 WordPress 通常从哪里被入侵，再逐步示范你今天可以在正式网站上采取的行动。

风险实际来自哪里

大部分 WordPress 事故都可追溯到几个原因：管理员密码太弱或重复使用、插件或主题未更新、集成被赋予超出需要的权限，以及从未测试过的备份。隐藏登录网址或 WordPress 版本并不能解决以上任何一项。以下步骤针对真正重要的成因。

步骤 1 — 盘点账户与集成

列出每个用户、每个应用密码及每个第三方连接。员工离职当日就移除其账户，并撤销不再使用之集成的令牌。你无法保护已遗忘的访问权。

步骤 2 — 修正认证方式

用密码管理器管理唯一密码。长度比强制复杂度更重要。现行 NIST 指引（SP 800-63B）偏好长密码短语，容许至少 64 个字符，并建议以已知外泄密码清单筛查新密码，而非强制组合规则及定期更换。
使用应用或硬件双重认证。TOTP 应用与安全密钥比短信验证码更强；后者可被截取或通过 SIM 卡交换破解。
情况允许时使用 passkey。Passkey 与硬件密钥（WebAuthn／FIDO2）可抵抗钓鱼，因为它们无法被输入到伪造登录页。WordPress 核心并未内置双重认证或 passkey 登录，需靠安全插件或主机／身份供应商登录提供。

步骤 3 — 套用最小权限

大部分撰写内容的人都不需要管理员角色。给每人完成工作所需的最低角色，并保留至少两个管理员以免被锁在门外；应用密码只用于确实需要它的集成。

步骤 4 — 修补核心、主题与插件

WordPress 7.1.2 于 2026 年 9 月 22 日发布，紧接 9 月 17 日的 7.1.1 维护及安全更新。公开回报的 WordPress 漏洞大多来自插件与主题而非核心，因此修补是最有价值的例行工作。可行时启用自动更新；涉及自定义代码时先在测试站验证；并删除不再使用的组件——停用的代码仍留在服务器上，仍需维护。

步骤 5 — 收窄暴露面

全站以 HTTPS 提供并将 HTTP 重定向。
依官方加固指引：正确的文件所有者与权限、收紧 wp-config.php 权限、以 DISALLOW_FILE_EDIT 停用内置文件编辑器，并使用只有 WordPress 所需权限的数据库用户。
如无必要集成使用 XML-RPC，封锁它。
Web 应用防火墙与登录频率限制可减少自动化滥用，但它们属补偿控制——不会修复有漏洞的插件或弱密码。
加入 HSTS、Content-Security-Policy、X-Content-Type-Options 等安全标头。

步骤 6 — 真正恢复过的备份

从未恢复过的备份只是假设。官方备份指引建议保留三至五份近期副本并存放在不同位置；常见的 3-2-1 原则（三份副本、两种介质、一份异地）是合理下限。备份要加密并限制访问，因为外泄的备份等于网站与数据库的完整副本。要测试恢复，而不只是执行备份。

步骤 7 — 监控与准备应变

定期检查用户清单、插件、计划任务与文件完整性。警号包括你未创建过的管理员账户、陌生的文件或 <code>mu-plugins</code>、非预期的对外邮件，以及无故出现的重定向。若网站被入侵，先保留日志与快照才清理，轮换所有凭证及 <code>wp-config.php</code> 的 WordPress salts，从事故前的备份恢复，然后更新并重新扫描。

快速检查清单

每个管理员在密码管理器中都有唯一密码。
管理员账户强制使用双重认证或 passkey。
已移除不再使用的用户、插件、主题及应用密码。
核心、主题与插件已更新，自定义代码已在测试站验证。
已强制 HTTPS，并套用官方指引的加固设置。
异地备份已加密，且已测试恢复。
你知道事故首小时要联系谁、要做什么。

Managed-WP 如何协助你

Managed-WP 提供托管 WordPress 云端主机，包括 24/7 支持、代管更新与备份，以及 Web 应用防火墙。若你不想独自承担以上清单，或想有人协助套用到正式网站，可到价格页比较方案、了解WP 安全与 OWASP 服务，或使用下方即时聊天告诉我们你的网站情况。