网站安全审计不是装个防火墙或者扫一遍漏洞就完事，它是对站点从域名解析、服务器配置、代码逻辑到权限管理的一次全面体检。多数站点被入侵的根源不是攻击者手段多高明，而是基础配置存在低级疏漏。下面直接拆解审计中必须核查的核心维度，以及每个维度具体要看什么、怎么查、查到问题怎么处理。

一、先查域名与DNS层：入口被劫持，后面全白费

域名是站点的第一道入口。审计第一步要确认域名注册信息是否归属公司主体，注册邮箱是否可用，域名是否开启注册商锁定和转移锁。很多老站点的域名注册邮箱早已废弃，攻击者一旦通过社工或泄露库拿到注册商账号，就能直接转移域名。接着查DNS解析记录，重点看是否存在陌生A记录、CNAME记录或MX记录。黑客拿到DNS控制权后，常会添加一条低权限子域名指向恶意服务器，用于钓鱼或中间人攻击。还要检查DNSSEC是否启用，未启用时DNS查询结果可被伪造。最后核对SPF、DKIM、DMARC记录，防止域名被用于伪造邮件。

二、服务器与网络层：暴露面决定攻击面

服务器配置审计的核心原则是“最小暴露”。先做端口扫描，只保留80、443等业务必需端口，22端口如果必须开放，应限制来源IP并改用密钥登录。检查防火墙规则是否默认拒绝，而不是默认允许。再查SSH配置，确认PermitRootLogin为no，PasswordAuthentication为no，使用密钥认证并设置登录失败锁定。Web服务器方面，Nginx或Apache要隐藏版本号，关闭目录浏览，限制请求体大小防止资源耗尽。还要检查TLS配置，禁用SSLv2、SSLv3、TLSv1.0和TLSv1.1，只保留TLSv1.2及以上版本，证书链完整且未过期。服务器上运行的服务越少越好，用systemctl或ps命令列出所有进程，停掉非必要服务。

三、应用层代码审计：漏洞重灾区

应用层是攻击者最常突破的位置。审计时先确认框架和依赖库版本，用依赖检查工具列出所有第三方组件，重点排查存在已知CVE的版本。SQL注入检查要看所有数据库查询是否使用参数化或预编译语句，任何字符串拼接SQL都应视为高危。跨站脚本检查关注输出点是否统一做HTML实体编码，尤其是富文本、评论、搜索回显等位置。文件上传功能必须校验文件类型、大小、内容头，并重命名存储，禁止可执行扩展名。权限控制要核查每个敏感接口是否校验登录态和角色，防止越权访问。还要检查是否开启CORS且配置过宽，是否设置安全的Cookie属性如HttpOnly、Secure、SameSite。

四、身份认证与权限管理：内部风险同样致命

后台账号体系是审计重点。先查管理员账号数量，禁用离职人员账号，删除测试账号和默认账号。密码策略要求至少12位，包含大小写字母、数字和特殊字符，禁止使用常见弱密码。登录接口必须有限速和验证码机制，防止暴力破解。多因素认证应为后台强制开启。权限分配遵循最小权限原则，普通编辑账号不应有系统设置权限。数据库账号同理，Web应用连接数据库的账号只授予所需库表的增删改查权限，禁止使用root。服务器上每个运维人员使用独立账号，操作留日志，禁用共享账号。

五、数据安全与备份：防丢失也防泄露

数据层审计要确认敏感数据是否加密存储。用户密码必须使用bcrypt、argon2等强哈希算法加盐存储，禁止明文或MD5。手机号、身份证号、银行卡号等个人信息在数据库中应加密存储，展示时脱敏。数据传输全程使用HTTPS，内部接口调用也建议走加密通道。备份策略要检查备份频率、备份存储位置是否与生产环境隔离、备份数据是否加密、恢复演练是否定期执行。很多站点被勒索后才发现备份和服务器在同一台机器上，一起被加密。日志方面，访问日志、错误日志、操作日志要保留至少六个月，且日志中不得记录密码、令牌等敏感信息。

六、文件系统与运行环境：权限漏洞常被忽略

Web目录权限设置不当会直接导致源码泄露或文件篡改。检查网站根目录所有者与Web进程用户是否分离，文件权限不应为777，目录一般755，文件一般644，需要写入的目录如上传目录、缓存目录设为775并限制执行权限。配置文件如.env、config.php等必须禁止外部访问，且不要提交到代码仓库。检查是否有备份文件、压缩包、编辑器临时文件残留在Web目录，这些文件常包含源码或数据库信息。运行环境方面，PHP要关闭危险函数如exec、system、eval，设置open_basedir限制文件访问范围。如果使用容器部署，镜像应使用非root用户运行，并定期更新基础镜像。

七、框架与CMS专项核查：别用默认配置上线

使用WordPress、ThinkPHP、Laravel等框架或CMS的站点，要专门核查框架自身的安全配置。CMS后台地址应修改默认路径，限制访问IP。插件和主题只保留必需的，删除未使用的，因为大量漏洞来自第三方插件。框架调试模式必须关闭，否则报错页面会泄露路径和代码片段。序列化、反序列化操作要检查数据来源是否可控。模板引擎如果允许用户输入，要确认已开启自动转义。定时任务、队列进程的运行权限也要核查，防止被利用执行恶意代码。版本更新策略要明确，安全补丁应在发布后一周内完成升级。

八、持续监控与应急响应：审计不是一次性动作

安全审计的最后一个环节是确认站点是否具备持续监控能力。检查是否部署了文件完整性监控，关键目录文件被修改时能否及时告警。Web应用防火墙规则是否覆盖常见攻击类型，是否开启实时防护。入侵检测系统或日志分析平台是否在运行，异常登录、异常请求、异常流量能否触发告警。应急响应预案要明确发现入侵后的处理流程：先隔离服务器、保留证据、分析入侵路径、修复漏洞、恢复数据、复盘改进。联系人名单和上报机制要清晰，避免事发后手忙脚乱。安全审计报告应形成书面文档，列出问题清单、严重等级、修复建议和责任人，并跟踪整改进度。

网站安全审计的价值在于发现那些“以为没问题”的隐患。上述每个检查项都可以落地为具体命令或工具操作，比如用nmap扫端口、用openssl查证书、用sqlmap验证注入、用lynis做系统基线检查。关键是审计要定期做、全面做，并且把发现的问题真正修复掉，而不是停留在报告里。安全状态是动态变化的，今天的审计结果只能代表当前这一刻，持续核查才能让站点始终保持在可控风险范围内。