WordPress 安全基线先看文件权限、wp-config、登录入口、插件更新和备份恢复，而不是先堆安全插件。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
WordPress 安全基线不需要一开始就上很复杂的 WAF 或企业级监控，而是先检查主机、文件权限、wp-config、登录入口、插件更新和备份恢复这几层。官方 Hardening 文档明确提到文件权限、wp-admin 保护、wp-config.php 保护和关闭文件编辑等做法。下面这份清单按顺序排，适合独立站长或小团队在没有专职安全人员时自查。
适用场景
- 你自己维护 WordPress 站点，但不清楚当前文件权限和 wp-config 是否过松。
- 你准备把站点从 demo 升级为正式业务，需要先补安全基线。
- 站点有多个管理员、插件或主题，需要明确谁可以改文件和安装代码。
- 你希望在攻击发生前确认备份能真正恢复，而不是只把备份文件放上去。
不适用场景
- 你只想通过插件扫描获得“安全”状态，不准备检查服务器配置。
- 你完全没有 SSH、FTP 或主机文件管理权限，无法执行权限和文件检查。
- 站点已经被入侵，你需要的不是基线而是隔离、取证和重建。
- 你准备禁用所有写权限，却不了解主题更新、插件更新和上传目录的写入需求。
准备材料
- WordPress 后台管理员账号和主机 SSH/FTP 权限。
- 当前插件、主题和 WordPress 版本清单。
- 数据库备份工具或主机自带备份功能。
- 一个隔离的测试环境，用来验证权限改动和恢复流程。
- 负责安全复查的人，以及紧急恢复联系方式。
步骤一：先建立站点台账和备份
官方 Hardening 文档把备份放在安全工作的准备阶段，而不是出事后再做。先记录 WordPress 版本、PHP 版本、数据库地址、插件主题清单和文件路径，再确认备份可以恢复到独立环境。没有经过恢复测试的备份只能算文件副本。
- 导出插件、主题和核心文件清单。
- 记录 wp-config.php 里的数据库前缀和账号用途。
- 做一次完整备份，包括数据库、wp-content、.htaccess 和 wp-config。
- 在测试环境恢复一次，确认网站能打开且插件正常。
步骤二：按最小需要设置文件权限
官方文件权限文档建议一般目录为 755，一般文件为 644，wp-config.php 可以收紧到 440 或 400。共享主机如果使用 suexec，PHP 以文件所有者运行，上传目录也不需要 777。权限改得太宽会让任意写入变成代码执行，改得太窄又会造成更新失败。
- 目录使用 755 或 750，不要使用 777。
- 普通文件使用 644 或 640，wp-config.php 使用 400 或 440。
- wp-content/uploads 需要写权限，但目录本身仍应避免 777。
- 检查 wp-content/cache 等插件目录是否有非必要全局写权限。
在 shell 中可以这样检查主要文件：
find /path/to/wordpress -type d -exec ls -ld {} \; | head -50
ls -l /path/to/wordpress/wp-config.php
步骤三：加固 wp-config.php 和文件编辑
官方文档建议把 wp-config.php 放在 WordPress 安装目录上一级，并用服务器配置阻止外部访问。另一个高价值项是关闭后台文件编辑器，因为它会让登录后的管理员直接改 PHP 文件。可以在 wp-config.php 中加入：
define( 'DISALLOW_FILE_EDIT', true );
这一行相当于移除 edit_themes、edit_plugins 和 edit_files 能力。不要只依赖主题设置里的禁用选项，因为攻击者一旦进入后台，最优先的动作就是改主题文件。
- 确认 wp-config.php 不在浏览器可访问目录。
- 在 wp-config.php 加入 DISALLOW_FILE_EDIT true。
- 检查表前缀是否仍使用默认 wp_，并确认数据库账号不是超级管理员。
- 不要让 wp-config.php 在日志、备份或版本控制中出现。
步骤四：保护登录和后台入口
官方文档提到可以用服务器端 BasicAuth 给 wp-admin 加第二层保护，但要注意 admin-ajax.php 等 AJAX 路径可能被破坏。更通用的做法是启用两步验证、限制登录尝试、禁用不需要的用户和检查审计日志。
- 管理员账号不使用 admin 作为用户名。
- 为所有可登录用户启用 2FA 或安全密钥。
- 限制登录尝试次数，并记录失败来源 IP。
- 移除长期不用的作者、编辑和管理员账号。
- 定期查看 wp_users 和最近登录记录，发现新管理员立即处理。
步骤五：控制插件、主题和自动更新边界
插件和主题是 WordPress 常见入口。官方建议只从可信来源安装，及时更新，并评估插件是否真的需要写权限。不要在正式环境随手安装来源不明的插件，也不要让所有用户都能安装插件。
- 把安装插件的权限限制给站点管理员或更低层级的特定角色。
- 对不再使用的插件先停用，确认没有依赖后删除。
- 记录每个插件的作用、更新频率和是否有特权操作。
- 更新前在测试环境验证，尤其是更新前有改动数据库的插件。
- 关闭文件编辑器后，确认主题和插件仍能通过后台正常更新。
步骤六：配置日志并做外部巡检
官方 Hardening 文档建议保留日志并定期检查站点状态。WordPress 自身 debug.log 不要在生产长期开启，但主机错误日志、安全插件日志和登录审计可以保留。还可以从外部检查首页、登录页、REST API 和 sitemap 是否可访问，确认没有暴露敏感文件。
- 检查 wp-config.php 的 WP_DEBUG 是否在生产关闭。
- 确认 wp-content/debug.log 不包含数据库凭据或堆栈。
- 检查常见敏感路径，例如 .git、.env、wp-config.php.bak。
- 外部检查登录页和 XML-RPC 是否按需关闭。
- 把异常登录、文件变更和插件变更通知发送给负责人。
可复制检查表
WordPress 版本：\nPHP 版本：\n文件目录权限：\n文件权限：\nwp-config.php 权限：\nDISALLOW_FILE_EDIT：\n表前缀：\n数据库账号权限：\n管理员用户名：\n2FA 状态：\n登录尝试限制：\n插件数量：\n未使用插件：\n自动更新策略：\n备份位置：\n最近恢复测试：\n日志位置：\n外部检查日期：实际例子：独立站从默认安装变成可维护的基线
一个内容站一直使用默认 admin 用户名，wp-config.php 是 644，后台文件编辑器开着，uploads 目录曾出现 777。站长先做了完整备份并在测试环境恢复，再把 wp-config.php 改到 400、加入 DISALLOW_FILE_EDIT true、把 admin 用户名换成普通账号并开启 2FA。随后删除两个不用插件，更新到当前版本。两周后主机报告扫描没有发现高危权限，站长也能确定备份可以恢复。
验收清单
- 备份已完整并经过恢复测试。
- 目录权限没有 777，普通文件权限符合主机要求。
- wp-config.php 权限已收紧，且不在公开目录。
- DISALLOW_FILE_EDIT 已启用。
- 管理员账号不是 admin，2FA 已开启。
- 未使用插件已删除，更新流程有测试环境。
- 生产 debug 日志关闭，敏感路径未暴露。
常见坑
- 把 uploads 设为 777，因为插件报权限错误。
- 关闭文件编辑器后，误以为主题就不能通过后台更新。
- 修改 wp-config.php 时没有备份，语法错误导致站点 500。
- 只测文件权限，不测备份恢复。
- 用安全插件替代主机层权限检查，报告全绿但真实配置过松。
- 把 wp-config.php 提交到 Git 或上传到公开目录。
排错路径
- 插件更新提示无法写入：检查 wp-content、plugins 目录归属和权限，而不是直接设 777。
- 修改权限后网站 500：先恢复 wp-config.php 原权限，再检查 PHP 错误日志。
- 2FA 无法登录：准备恢复码或主机层临时绕过，不要直接删用户表。
- 后台编辑器消失：确认 DISALLOW_FILE_EDIT 已设置，这是预期行为。
- 备份恢复失败：分别测试数据库导入和文件上传，确认 wp-config 中的数据库名、用户和密码匹配。
后续维护建议
更新日期：2026-08-16。建议每月检查一次文件权限、登录失败记录和未使用插件，每季度做一次完整备份恢复测试，每次 WordPress 大版本升级前再对照官方 Hardening 文档。权限和备份是基线，不是一次做完就永久有效的状态；新增目录、插件或迁移主机后都要重新检查。