网站上线前的安全检查清单

上线前要查的不只是“能不能打开”

网站开发完成、页面能正常访问，离真正可以上线还有一段距离。个人网站虽然没有大型平台的流量压力，但爬虫、扫描、弱密码爆破这些自动化攻击并不会因为站点小就绕道。上线前的安全检查，重点落在账号、目录、密钥、后台入口和文件权限这几个方面，而不是只确认首页显示正常。

检查的顺序也值得讲究。先明确网站的使用场景、访客身份和不允许公开的资源，再逐项核对配置。否则一边改一边猜，很容易漏掉某个本应限制的入口，或者把不该开放的文件目录暴露出去。

账号与密钥：默认设置是第一个风险点

管理员密码是上线后最早需要处理的项目。安装完程序或面板后，默认密码往往简单且公开可查，必须立即修改。修改时不要只换一个字母或数字，直接生成一段足够长的随机密码更稳妥。

API Key、数据库连接串、支付回调密钥这类敏感信息，不能写进源码文件。常见的错误是把密钥写在配置文件中并随代码一起提交到 Git 仓库，或者放在 Web 根目录下能被直接访问的位置。正确做法是把密钥放在 Web 根目录之外的配置文件中，通过环境变量或配置文件引入。上线前要逐一检查代码目录里有没有残留的 .env、config.php、settings.py 这类文件，并确认它们不会被 HTTP 请求直接读取。

检查方法很简单：在浏览器里直接访问这些文件的 URL，如果返回了文件内容而不是 403 或 404，说明目录权限配置有问题，需要立即修复。

后台入口与搜索引擎抓取控制

后台登录页面、上传目录、私有下载目录这三类路径，默认不应该被搜索引擎收录。robots.txt 可以声明禁止抓取的路径，但要清楚它只是君子协定，并不能阻止恶意爬虫。真正的访问控制要靠目录权限和认证机制来实现。

具体检查时，确认后台目录是否设置了额外的访问限制，上传目录是否禁用了脚本执行权限。上传功能要限制文件类型和后缀，不能允许用户上传 PHP、JSP 这类可执行文件，同时要把上传文件存储到 Web 根目录之外，或者通过程序重命名文件并校验 MIME 类型。路径方面，要防止用户通过构造文件名访问到其他目录的文件，上传目录的访问权限应设置为不可列出目录列表。

文件权限与目录结构

文件权限设置不当是另一个常见隐患。Web 根目录下的文件应尽量设置为只读，只有需要写入的目录（如上传目录、缓存目录）才开放写权限。运行 Web 服务的用户不应该对配置文件拥有写权限，否则一旦程序存在漏洞，攻击者可能通过写入文件来获得控制权。

检查时可以用命令查看关键目录的属主和权限位，确认没有出现“所有用户可写”的情况。备份文件、数据库导出文件、日志文件如果存放在 Web 根目录内，要确认它们不会被直接下载。常见的错误是把 backup.sql、site.zip 这类文件放在根目录下，任何人都可以通过 URL 直接下载。

日志、备份与磁盘空间

网站能打开只是表面现象。错误日志中可能记录了数据库连接失败、文件写入失败、被拒绝的异常请求等信息，这些内容才是判断系统是否健康的第一手资料。上线前要确认错误日志已开启，并且日志文件路径不在 Web 根目录下。上线后的一段时间内要定期查看日志，观察是否有异常的登录尝试、扫描行为或程序报错。

备份策略要在上线前就确定，而不是等出了问题再想。至少需要确认备份文件的存放位置、备份频率和恢复方法。备份文件不能存放在网站根目录内，最好下载到本地或存储到其他服务器。磁盘空间也要检查，日志文件如果不做轮转或清理，会持续增长直到占满磁盘，导致网站无法写入会话或缓存文件。

容易被忽略的细节

实际维护中，下面几项经常被遗漏：

• 只关注网站首页能打开，忽略了错误日志、备份可用性和磁盘剩余空间。
• 后台地址、上传目录和私有资源没有做访问控制，被搜索引擎收录或被人直接猜出路径。
• 没有记录配置变更和登录行为，后期出现问题时缺少排查依据。

这些细节不会出现在页面效果图上，但会直接影响后续维护效率。遇到异常时，先保留现场——包括日志、配置文件、当前状态——再逐项排查，不要在原因不明时同时修改多个地方，否则很难判断是哪一项改动导致了新问题。

上线后的持续检查

上线不是安全检查的终点。登录失败限制和后台操作审计可以在上线后逐步补充，前者能减缓暴力破解，后者能在出现异常时追溯操作来源。每次修改配置后，要重新确认相关功能是否正常，并记录变更内容。

对于个人网站来说，安全检查的最终目的是让维护者清楚知道：哪些入口是开放的、哪些文件是敏感的、出了问题从哪里查起。把这些信息整理成一份自己能看懂的清单，比记住一堆零散的命令更有用。