WordPress链接数据库文件夹配置失误导致数据泄露，3步完成性能优化与安全加固
改个需求建站公司拖一周，这种经历谁懂？更让人心梗的是，因为对方图省事，直接把WordPress的配置文件暴露在了公网，导致数据库密码明文可见。这不是危言耸听，这是很多中小企业官网的常态。很多甲方以为只要网站能打开、页面不卡顿，就是“性能优化”到位了，其实大错特错。真正的性能优化，底层是安全架构的稳固。如果地基（数据库连接配置）有裂缝，上面盖的楼再漂亮，被黑客一推就塌，或者被搜索引擎判定为高风险站点，流量直接归零。
今天我们就拆解一个高频且致命的场景：WordPress如何正确“链接”数据库，以及那个被忽视的文件夹配置陷阱。我们将通过时间线视角，复盘一次典型的数据泄露事件，并给出从检测到修复的完整实操方案。
威胁场景：一次“顺手”的目录浏览引发的灾难
想象一下，你的官网上线三个月，业务量稳定，SEO排名也不错。某天下午，你收到Google Search Console的邮件提醒，说网站存在不安全内容，或者某些URL被标记为“恶意软件”。你第一反应是懵的：我用的都是正版插件，服务器也装了防火墙，怎么会有恶意软件？
登录后台一看，网站还能访问，但后台登录页面异常缓慢，甚至直接报错500。这时候你找之前的建站公司，对方回复：“我们查一下，需要时间。”这一查，就是三天。
在这三天里，发生了什么？
黑客并不是通过复杂的SQL注入攻击进来的，他们只是用了最基本的工具：DirBuster或者Gobuster，对网站根目录进行了一次简单的字典扫描。他们发现了一个名为.env或者wp-config.php.bak的文件，甚至更糟糕的是，他们直接访问了/wp-includes/目录下的某些敏感文件，或者发现了数据库配置文件未被正确隐藏。
在很多低质量的WordPress部署中，为了调试方便，开发人员会将wp-config.php放在容易访问的位置，或者没有正确设置文件权限。更常见的情况是，服务器配置不当，允许目录列表浏览（Directory Listing）。黑客只需要在浏览器输入http://your-domain.com/wp-admin/或http://your-domain.com/wp-content/uploads/，如果服务器配置允许，他们会看到一个文件列表，里面赫然躺着wp-config.php的备份文件，或者包含数据库凭据的.env文件。
一旦拿到了数据库的用户名、密码和主机地址，黑客就可以通过MySQL客户端直接连接数据库。他们可以删除内容、篡改管理员密码，甚至植入后门代码。对于甲方来说，这意味着品牌声誉受损、客户数据泄露，以及高昂的修复成本。更讽刺的是，这一切本可以通过正确的文件夹权限配置和文件隐藏规则来避免。而所谓的“性能优化”，如果建立在这样脆弱的配置上，只是让漏洞暴露得更快。
漏洞原理：为什么“链接”数据库时文件夹配置如此关键？
WordPress的核心在于wp-config.php文件。这个文件定义了WordPress如何“链接”到你的MySQL数据库。它包含了四个关键变量：DB_NAME（数据库名）、DB_USER（用户名）、DB_PASSWORD（密码）、DB_HOST（主机地址）。
问题的核心不在于代码逻辑，而在于文件系统的权限管理和Web服务器的访问控制。
1. 文件权限配置错误
Linux系统下的文件权限分为三组：所有者（Owner）、所属组（Group）、其他人（Others）。正确做法：wp-config.php应该仅被Web服务器用户（如www-data或nginx）读取和执行，其他所有用户（包括Web服务器进程本身，除非必要）不应有写入权限，且普通SSH用户也不应轻易读取明文密码。
常见错误：文件权限被设置为644（可读可写，其他用户可读）甚至777（所有人可读可写可执行）。如果权限是644，虽然Web服务器能读，但如果Web服务器存在任意文件读取漏洞（如LFI本地文件包含攻击），黑客就可以通过构造特定的URL，让服务器读取这个文件并返回内容。2. 目录列表浏览未关闭
很多共享主机或配置不当的VPS，默认开启了Apache的Indexes选项。这意味着，如果一个目录下没有index.php或index.html文件，Apache会自动列出该目录下的所有文件。场景：如果黑客访问http://your-domain.com/，而该目录下恰好有一个备份文件wp-config.php.old，且没有index.php，Apache就会直接显示这个文件的名字。
后果：黑客点击文件名，直接下载了包含数据库密码的配置文件。3. 备份文件未清理
这是建站公司最懒的做法。为了保留“原始”配置，他们会将wp-config.php复制为wp-config.php.bak或config.old放在根目录或wp-includes目录下。这些文件通常不会被WordPress核心加载，因此即使权限设置正确，它们也不会被Web服务器“特殊处理”。如果目录浏览开启，或者文件名被猜到，这些备份文件就是直接的数据泄露通道。
4. .env 文件暴露
现代WordPress部署越来越倾向于使用.env文件来管理环境变量，而不是硬编码在wp-config.php中。.env文件通常位于站点根目录。如果Web服务器配置不当，允许下载.env文件，或者文件权限过于宽松，其中的数据库凭证同样会泄露。
核心逻辑：WordPress“链接”数据库的过程，本质上是PHP脚本读取配置文件，获取凭证，建立连接。如果配置文件所在的“文件夹”或“文件”本身对非授权访问开放，整个链接过程的安全性就形同虚设。性能优化的前提是稳定，而稳定的前提是安全。
防护方案：配置代码与文件夹权限的双重锁
解决这个问题的思路很简单：最小权限原则 + 访问控制。我们需要确保只有Web服务器进程能读取数据库凭证，其他任何人（包括通过HTTP请求的外部用户）都无法触及这些文件。
1. 文件权限精细化设置
登录你的服务器，执行以下命令（假设你的网站根目录是/var/www/html，Web服务器用户是www-data）：
# 1. 确保wp-config.php权限为440，所有者为root，组为www-data
# 这意味着：root可读，www-data组可读，其他人无权限
chown root:www-data /var/www/html/wp-config.php
chmod 440 /var/www/html/wp-config.php# 2. 确保.env文件（如果存在）权限同样为440
chown root:www-data /var/www/html/.env
chmod 440 /var/www/html/.env# 3. 其他核心文件（wp-load.php等）建议为444，目录为755
# 目录需要x权限才能进入，文件不需要x权限（除非是PHP执行）
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
# 最后再次单独收紧wp-config.php
chmod 440 /var/www/html/wp-config.php代码对比：
错误配置（高危）：
; Apache httpd.conf 或虚拟主机配置
Directory /var/www/htmlOptions +Indexes +FollowSymLinksAllowOverride AllRequire all granted
/Directory+Indexes：开启目录列表浏览。
AllowOverride All：允许.htaccess文件覆盖配置，增加了攻击面。正确配置（安全）：
; Apache httpd.conf 或虚拟主机配置
Directory /var/www/htmlOptions -Indexes +FollowSymLinksAllowOverride NoneRequire all granted
/Directory# 额外防护：禁止访问敏感文件和目录
FilesMatch ^\.Require all denied
/FilesMatchFilesMatch wp-config\.php.*Require all denied
/FilesMatch# 禁止访问wp-admin目录的直接文件访问（通过URL）
# 注意：这不会阻止正常的后台访问，因为后台访问是通过wp-admin/index.php
# 但能阻止直接访问wp-admin/下的php文件如install.php等
Directory /var/www/html/wp-adminFilesMatch \.(php)$# 这里不能简单deny所有php，否则后台进不去# 更好的做法是依赖WordPress自身的权限控制# 或者在Nginx中更精确地控制/FilesMatch
/DirectoryNginx 配置示例（更推荐）：
Nginx的性能优化能力更强，且配置更直观。
server {listen 80;server_name your-domain.com;root /var/www/html;index index.php index.html;# 性能优化：开启缓存location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2)$ {expires 1y;add_header Cache-Control public, immutable;access_log off;}# 安全加固：禁止访问隐藏文件location ~ /\. {deny all;access_log off;log_not_found off;}# 安全加固：禁止访问wp-config.php及备份文件location ~* /wp-config\.php.* {deny all;access_log off;log_not_found off;}# 安全加固：禁止访问wp-includes目录下的直接文件location ~* /wp-includes/.*\.php {deny all;}# 标准PHP处理location ~ \.php$ {include snippets/fastcgi-php.conf;fastcgi_pass unix:/run/php/php8.1-fpm.sock;}
}关键点解析：Options -Indexes：关闭目录列表，黑客无法浏览文件夹内容。
FilesMatch：明确拒绝访问以.开头的文件（如.env, .htaccess）和wp-config.php及其任何后缀的备份文件。
chmod 440：即使Web服务器配置出错，操作系统层面的权限也能阻止其他用户读取文件。2. 移除不必要的备份文件
立即检查网站根目录、wp-content、wp-includes等目录，删除所有.bak, .old, .save, .txt等后缀的配置文件备份。如果确实需要备份，请将其存储在服务器本地非Web根目录下，或使用安全的加密压缩工具。
检测与修复：如何验证你的网站是否“裸奔”？
不要等黑客来测试，你自己先测。
1. 手动测试目录浏览
在浏览器地址栏输入以下URL，看是否返回文件列表：http://your-domain.com/
http://your-domain.com/wp-content/
http://your-domain.com/wp-includes/
http://your-domain.com/wp-admin/如果看到HTML表格形式的文件列表，说明目录浏览未关闭。
2. 尝试访问敏感文件
尝试访问以下URL，看是否返回200状态码（成功）或文件内容：http://your-domain.com/wp-config.php
http://your-domain.com/.env
http://your-domain.com/wp-config.php.bak
http://your-domain.com/config.old如果返回403 Forbidden或404 Not Found，说明防护生效。如果返回文件内容或数据库报错信息，立即修改配置。
3. 使用在线工具扫描
使用Nuclei、Nmap或在线的DirBuster扫描器对网站进行一次全面的目录扫描。关注那些返回200状态码且文件名包含config, env, sql, db, backup等关键词的文件。
4. Google Search Console 监控
定期查看Google Search Console中的“手动操作”和“安全问题”报告。如果Google检测到你的网站有暴露的配置文件，可能会发出警告。这是外部视角的重要参考。
修复流程：停止服务（可选，如果时间允许，短暂重启Web服务以应用配置变更）。
修改文件权限：执行上述chmod和chown命令。
更新Web服务器配置：修改Apache或Nginx配置文件，添加deny规则。
清理备份文件：删除所有可疑的备份文件。
重载配置：systemctl reload nginx 或 systemctl reload apache2。
重新测试：重复上述检测步骤，确保所有敏感文件不可访问。
更新数据库密码：如果之前已经泄露，立即修改MySQL数据库密码，并更新wp-config.php中的DB_PASSWORD。安全加固清单：甲方对接人的必查项
作为甲方，你在验收网站或日常运维时，可以要求建站公司提供以下安全加固清单的证明。这不是挑刺，这是保护你的资产。检查项
标准
验证方式文件权限
wp-config.php权限为440或640，属主为root，属组为Web用户
SSH执行ls -l wp-config.php目录浏览
所有Web目录关闭Indexes选项
浏览器访问目录URL，应返回403或404敏感文件隐藏
.env, .htaccess, wp-config.php不可通过HTTP访问
浏览器直接访问URL，应返回403或404备份文件清理
Web根目录下无.bak, .old, .txt等配置文件备份
SSH执行find . -name *.bak -o -name *.oldHTTPS强制
所有HTTP请求重定向到HTTPS，启用HSTS
访问HTTP URL，应自动跳转；查看响应头Strict-Transport-Security数据库隔离
数据库用户仅拥有该特定数据库的权限，无全局权限
使用数据库用户登录MySQL，执行SHOW GRANTS;错误报告关闭
生产环境display_errors设为Off
故意触发一个PHP错误，看页面是否显示详细错误信息SSL证书有效性
证书未过期，且覆盖所有子域名
浏览器地址栏锁头图标；使用openssl s_client检查WordPress版本
使用最新稳定版，插件和主题无已知高危漏洞
WordPress后台“更新”页面；使用WPScan扫描登录保护
后台登录有限流、CAPTCHA或多因素认证(MFA)
尝试多次错误登录，看是否被锁定；检查是否支持2FA特别提示：
性能优化和安全加固不是对立的。一个安全的网站，其配置通常更加规范，缓存策略更合理，从而间接提升了性能。例如，关闭目录浏览减少了不必要的I/O操作；合理的文件权限避免了潜在的文件注入攻击导致的资源耗尽。
很多建站公司把“性能优化”简单等同于“加个CDN”或“压缩图片”，这是浅层的。真正的性能优化，是构建一个稳定、安全、可维护的技术架构。当你的网站因为配置错误而被攻击，导致服务器CPU飙升、数据库连接池耗尽时，再谈性能优化就是笑话。
作为甲方，你不需要成为黑客，但你必须懂得问对问题。下次建站公司说“配置好了”，请追问一句：“wp-config.php的权限是多少？目录浏览关了吗？备份文件删了吗？”
你的网站用的什么技术栈？是传统的PHP+MySQL，还是正在尝试Node.js或Go？评论区聊聊，看看有多少人的网站存在同样的隐患。
WordPress链接数据库文件夹配置失误导致数据泄露，3步完成性能优化与安全加固
WordPress链接数据库文件夹配置失误导致数据泄露，3步完成性能优化与安全加固
改个需求建站公司拖一周，这种经历谁懂？更让人心梗的是，因为对方图省事，直接把WordPress的配置文件暴露在了公网，导致数据库密码明文可见。这不是危言耸听，这是很多中小企业官网的常态。很多甲方以为只要网站能打开、页面不卡顿，就是“性能优化”到位了，其实大错特错。真正的性能优化，底层是安全架构的稳固。如果地基（数据库连接配置）有裂缝，上面盖的楼再漂亮，被黑客一推就塌，或者被搜索引擎判定为高风险站点，流量直接归零。
今天我们就拆解一个高频且致命的场景：WordPress如何正确“链接”数据库，以及那个被忽视的文件夹配置陷阱。我们将通过时间线视角，复盘一次典型的数据泄露事件，并给出从检测到修复的完整实操方案。
威胁场景：一次“顺手”的目录浏览引发的灾难
想象一下，你的官网上线三个月，业务量稳定，SEO排名也不错。某天下午，你收到Google Search Console的邮件提醒，说网站存在不安全内容，或者某些URL被标记为“恶意软件”。你第一反应是懵的：我用的都是正版插件，服务器也装了防火墙，怎么会有恶意软件？
登录后台一看，网站还能访问，但后台登录页面异常缓慢，甚至直接报错500。这时候你找之前的建站公司，对方回复：“我们查一下，需要时间。”这一查，就是三天。
在这三天里，发生了什么？
黑客并不是通过复杂的SQL注入攻击进来的，他们只是用了最基本的工具：DirBuster或者Gobuster，对网站根目录进行了一次简单的字典扫描。他们发现了一个名为.env或者wp-config.php.bak的文件，甚至更糟糕的是，他们直接访问了/wp-includes/目录下的某些敏感文件，或者发现了数据库配置文件未被正确隐藏。
在很多低质量的WordPress部署中，为了调试方便，开发人员会将wp-config.php放在容易访问的位置，或者没有正确设置文件权限。更常见的情况是，服务器配置不当，允许目录列表浏览（Directory Listing）。黑客只需要在浏览器输入http://your-domain.com/wp-admin/或http://your-domain.com/wp-content/uploads/，如果服务器配置允许，他们会看到一个文件列表，里面赫然躺着wp-config.php的备份文件，或者包含数据库凭据的.env文件。
一旦拿到了数据库的用户名、密码和主机地址，黑客就可以通过MySQL客户端直接连接数据库。他们可以删除内容、篡改管理员密码，甚至植入后门代码。对于甲方来说，这意味着品牌声誉受损、客户数据泄露，以及高昂的修复成本。更讽刺的是，这一切本可以通过正确的文件夹权限配置和文件隐藏规则来避免。而所谓的“性能优化”，如果建立在这样脆弱的配置上，只是让漏洞暴露得更快。
漏洞原理：为什么“链接”数据库时文件夹配置如此关键？
WordPress的核心在于wp-config.php文件。这个文件定义了WordPress如何“链接”到你的MySQL数据库。它包含了四个关键变量：DB_NAME（数据库名）、DB_USER（用户名）、DB_PASSWORD（密码）、DB_HOST（主机地址）。
问题的核心不在于代码逻辑，而在于文件系统的权限管理和Web服务器的访问控制。
1. 文件权限配置错误
Linux系统下的文件权限分为三组：所有者（Owner）、所属组（Group）、其他人（Others）。正确做法：wp-config.php应该仅被Web服务器用户（如www-data或nginx）读取和执行，其他所有用户（包括Web服务器进程本身，除非必要）不应有写入权限，且普通SSH用户也不应轻易读取明文密码。
常见错误：文件权限被设置为644（可读可写，其他用户可读）甚至777（所有人可读可写可执行）。如果权限是644，虽然Web服务器能读，但如果Web服务器存在任意文件读取漏洞（如LFI本地文件包含攻击），黑客就可以通过构造特定的URL，让服务器读取这个文件并返回内容。2. 目录列表浏览未关闭
很多共享主机或配置不当的VPS，默认开启了Apache的Indexes选项。这意味着，如果一个目录下没有index.php或index.html文件，Apache会自动列出该目录下的所有文件。场景：如果黑客访问http://your-domain.com/，而该目录下恰好有一个备份文件wp-config.php.old，且没有index.php，Apache就会直接显示这个文件的名字。
后果：黑客点击文件名，直接下载了包含数据库密码的配置文件。3. 备份文件未清理
这是建站公司最懒的做法。为了保留“原始”配置，他们会将wp-config.php复制为wp-config.php.bak或config.old放在根目录或wp-includes目录下。这些文件通常不会被WordPress核心加载，因此即使权限设置正确，它们也不会被Web服务器“特殊处理”。如果目录浏览开启，或者文件名被猜到，这些备份文件就是直接的数据泄露通道。
4. .env 文件暴露
现代WordPress部署越来越倾向于使用.env文件来管理环境变量，而不是硬编码在wp-config.php中。.env文件通常位于站点根目录。如果Web服务器配置不当，允许下载.env文件，或者文件权限过于宽松，其中的数据库凭证同样会泄露。
核心逻辑：WordPress“链接”数据库的过程，本质上是PHP脚本读取配置文件，获取凭证，建立连接。如果配置文件所在的“文件夹”或“文件”本身对非授权访问开放，整个链接过程的安全性就形同虚设。性能优化的前提是稳定，而稳定的前提是安全。
防护方案：配置代码与文件夹权限的双重锁
解决这个问题的思路很简单：最小权限原则 + 访问控制。我们需要确保只有Web服务器进程能读取数据库凭证，其他任何人（包括通过HTTP请求的外部用户）都无法触及这些文件。
1. 文件权限精细化设置
登录你的服务器，执行以下命令（假设你的网站根目录是/var/www/html，Web服务器用户是www-data）：
# 1. 确保wp-config.php权限为440，所有者为root，组为www-data
# 这意味着：root可读，www-data组可读，其他人无权限
chown root:www-data /var/www/html/wp-config.php
chmod 440 /var/www/html/wp-config.php# 2. 确保.env文件（如果存在）权限同样为440
chown root:www-data /var/www/html/.env
chmod 440 /var/www/html/.env# 3. 其他核心文件（wp-load.php等）建议为444，目录为755
# 目录需要x权限才能进入，文件不需要x权限（除非是PHP执行）
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
# 最后再次单独收紧wp-config.php
chmod 440 /var/www/html/wp-config.php代码对比：
错误配置（高危）：
; Apache httpd.conf 或虚拟主机配置
Directory /var/www/htmlOptions +Indexes +FollowSymLinksAllowOverride AllRequire all granted
/Directory+Indexes：开启目录列表浏览。
AllowOverride All：允许.htaccess文件覆盖配置，增加了攻击面。正确配置（安全）：
; Apache httpd.conf 或虚拟主机配置
Directory /var/www/htmlOptions -Indexes +FollowSymLinksAllowOverride NoneRequire all granted
/Directory# 额外防护：禁止访问敏感文件和目录
FilesMatch ^\.Require all denied
/FilesMatchFilesMatch wp-config\.php.*Require all denied
/FilesMatch# 禁止访问wp-admin目录的直接文件访问（通过URL）
# 注意：这不会阻止正常的后台访问，因为后台访问是通过wp-admin/index.php
# 但能阻止直接访问wp-admin/下的php文件如install.php等
Directory /var/www/html/wp-adminFilesMatch \.(php)$# 这里不能简单deny所有php，否则后台进不去# 更好的做法是依赖WordPress自身的权限控制# 或者在Nginx中更精确地控制/FilesMatch
/DirectoryNginx 配置示例（更推荐）：
Nginx的性能优化能力更强，且配置更直观。
server {listen 80;server_name your-domain.com;root /var/www/html;index index.php index.html;# 性能优化：开启缓存location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2)$ {expires 1y;add_header Cache-Control public, immutable;access_log off;}# 安全加固：禁止访问隐藏文件location ~ /\. {deny all;access_log off;log_not_found off;}# 安全加固：禁止访问wp-config.php及备份文件location ~* /wp-config\.php.* {deny all;access_log off;log_not_found off;}# 安全加固：禁止访问wp-includes目录下的直接文件location ~* /wp-includes/.*\.php {deny all;}# 标准PHP处理location ~ \.php$ {include snippets/fastcgi-php.conf;fastcgi_pass unix:/run/php/php8.1-fpm.sock;}
}关键点解析：Options -Indexes：关闭目录列表，黑客无法浏览文件夹内容。
FilesMatch：明确拒绝访问以.开头的文件（如.env, .htaccess）和wp-config.php及其任何后缀的备份文件。
chmod 440：即使Web服务器配置出错，操作系统层面的权限也能阻止其他用户读取文件。2. 移除不必要的备份文件
立即检查网站根目录、wp-content、wp-includes等目录，删除所有.bak, .old, .save, .txt等后缀的配置文件备份。如果确实需要备份，请将其存储在服务器本地非Web根目录下，或使用安全的加密压缩工具。
检测与修复：如何验证你的网站是否“裸奔”？
不要等黑客来测试，你自己先测。
1. 手动测试目录浏览
在浏览器地址栏输入以下URL，看是否返回文件列表：http://your-domain.com/
http://your-domain.com/wp-content/
http://your-domain.com/wp-includes/
http://your-domain.com/wp-admin/如果看到HTML表格形式的文件列表，说明目录浏览未关闭。
2. 尝试访问敏感文件
尝试访问以下URL，看是否返回200状态码（成功）或文件内容：http://your-domain.com/wp-config.php
http://your-domain.com/.env
http://your-domain.com/wp-config.php.bak
http://your-domain.com/config.old如果返回403 Forbidden或404 Not Found，说明防护生效。如果返回文件内容或数据库报错信息，立即修改配置。
3. 使用在线工具扫描
使用Nuclei、Nmap或在线的DirBuster扫描器对网站进行一次全面的目录扫描。关注那些返回200状态码且文件名包含config, env, sql, db, backup等关键词的文件。
4. Google Search Console 监控
定期查看Google Search Console中的“手动操作”和“安全问题”报告。如果Google检测到你的网站有暴露的配置文件，可能会发出警告。这是外部视角的重要参考。
修复流程：停止服务（可选，如果时间允许，短暂重启Web服务以应用配置变更）。
修改文件权限：执行上述chmod和chown命令。
更新Web服务器配置：修改Apache或Nginx配置文件，添加deny规则。
清理备份文件：删除所有可疑的备份文件。
重载配置：systemctl reload nginx 或 systemctl reload apache2。
重新测试：重复上述检测步骤，确保所有敏感文件不可访问。
更新数据库密码：如果之前已经泄露，立即修改MySQL数据库密码，并更新wp-config.php中的DB_PASSWORD。安全加固清单：甲方对接人的必查项
作为甲方，你在验收网站或日常运维时，可以要求建站公司提供以下安全加固清单的证明。这不是挑刺，这是保护你的资产。检查项
标准
验证方式文件权限
wp-config.php权限为440或640，属主为root，属组为Web用户
SSH执行ls -l wp-config.php目录浏览
所有Web目录关闭Indexes选项
浏览器访问目录URL，应返回403或404敏感文件隐藏
.env, .htaccess, wp-config.php不可通过HTTP访问
浏览器直接访问URL，应返回403或404备份文件清理
Web根目录下无.bak, .old, .txt等配置文件备份
SSH执行find . -name *.bak -o -name *.oldHTTPS强制
所有HTTP请求重定向到HTTPS，启用HSTS
访问HTTP URL，应自动跳转；查看响应头Strict-Transport-Security数据库隔离
数据库用户仅拥有该特定数据库的权限，无全局权限
使用数据库用户登录MySQL，执行SHOW GRANTS;错误报告关闭
生产环境display_errors设为Off
故意触发一个PHP错误，看页面是否显示详细错误信息SSL证书有效性
证书未过期，且覆盖所有子域名
浏览器地址栏锁头图标；使用openssl s_client检查WordPress版本
使用最新稳定版，插件和主题无已知高危漏洞
WordPress后台“更新”页面；使用WPScan扫描登录保护
后台登录有限流、CAPTCHA或多因素认证(MFA)
尝试多次错误登录，看是否被锁定；检查是否支持2FA特别提示：
性能优化和安全加固不是对立的。一个安全的网站，其配置通常更加规范，缓存策略更合理，从而间接提升了性能。例如，关闭目录浏览减少了不必要的I/O操作；合理的文件权限避免了潜在的文件注入攻击导致的资源耗尽。
很多建站公司把“性能优化”简单等同于“加个CDN”或“压缩图片”，这是浅层的。真正的性能优化，是构建一个稳定、安全、可维护的技术架构。当你的网站因为配置错误而被攻击，导致服务器CPU飙升、数据库连接池耗尽时，再谈性能优化就是笑话。
作为甲方，你不需要成为黑客，但你必须懂得问对问题。下次建站公司说“配置好了”，请追问一句：“wp-config.php的权限是多少？目录浏览关了吗？备份文件删了吗？”
你的网站用的什么技术栈？是传统的PHP+MySQL，还是正在尝试Node.js或Go？评论区聊聊，看看有多少人的网站存在同样的隐患。
