业务上线前不做安全自检，等于把大门钥匙挂在门口。 上线前花几个小时做一次系统自检，能挡掉大部分常见攻击，这个自检不是给安全团队交差，而是给业务买保险，很多团队把安全放在上线之后，结果等来的不是用户增长，而是勒索邮件和降级通知。
网站上线前安全检查怎么做？先盘清家底再谈防护
资产盘点：漏掉一个子域名就可能被撕开口子
- 列出所有域名、IP、端口和服务，包括测试环境和预发布环境。
- 用nmap扫一遍开放端口,用wappalyzer识别技术栈，把结果整理成表格。
- 重点排查后台路径、API接口、运维管理页面是否暴露在公网。
实际操作中,相当一部分入侵事件是从一个无人维护的旧子域名开始的，这个子域名指向一台停用的云服务器，安全组还开着3389端口，所以资产清单里必须包含负责人和联系方式，每个条目都要有归属。
登录认证：默认密码是黑客的敲门砖
- 检查系统是否存在默认账号、弱口令、测试密码。
- 验证码能否绕过后台或接口直接请求。
- 登录成功后是否更换session,旧session是否立即失效。
建议用hydra对管理后台做一次弱口令测试,不要只在页面输入几个常见密码，行业共识认为：上线前至少做一轮渗透测试，比事后应急成本低一个数量级，如果团队没有专职安全人员，也可以使用云平台的基线检查工具。
业务逻辑：越权和支付金额篡改必须测
- 登录普通用户后,尝试修改URL中的ID访问其他用户订单。
- 提交订单时,把金额从100改成0.01。
- 手机验证码接口是否限制频率和次数。
这些漏洞很多漏洞扫描器测不出来,需要手工用Burp Suite抓包改包，开发人员往往只关注功能是否正常，忽略了“反着用”的场景。
业务系统上线前安全测试方案：从登录入口开始逐层排查
输入输出：注入和XSS不能只看有没有
- 对每个输入点分别测试SQL注入、XSS、命令注入和文件上传。
- 测试不要只在文本框进行,HTTP头部、Cookie、URL参数都是攻击入口。
- 上传功能不仅要验证后缀,还要校验文件内容和解析规则。
建议用sqlmap检测数据库类型和注入点,用dirsearch扫目录看有没有敏感备份文件。国内云厂商的漏洞扫描服务也能覆盖大部分常见问题，但自定义业务逻辑漏洞仍然需要人工复核。
安全配置：默认页面和错误信息会泄露版本号
- 关闭目录浏览功能,删除tomcat默认页面，自定义404错误页。
- 在响应头中隐藏服务器版本和框架标识。
- 为cookie设置HttpOnly和Secure属性,开启HSTS。
这些配置项看着琐碎,但黑客可以通过版本号搜索引擎匹配已知漏洞库，一套规范的云服务器安全配置教程通常包含这些内容：SSH禁止root登录、修改默认端口、安全组最小化放行、启用系统防火墙。
云服务器安全配置教程：改掉默认密码只是第一步
SSH和远程管理
- 修改SSH端口,禁用root账号直接登录，改用密钥认证。
- 在安全组中限制远程管理端口的访问IP为办公网段。
- 关闭不用的服务和端口,等待上线时再按需开启。
数据访问权限
- 数据库尽量不要开放公网访问,改用内网连接。
- 为不同业务创建独立账号,按最小权限分配。
- 备份数据加密存储,权限设为仅管理员可读。
基线加固：参考等保要求做一次体检
多数云平台提供免费的安全基线核查,可以快速发现配置薄弱点，比如服务器密码策略、登录失败锁定、日志保存周期等，如果业务需要过等保二级，建议直接咨询当地测评机构，了解具体整改要求。
网站安全防护哪家好？按业务场景选型不踩坑
先区分WAF、主机安全、云防火墙的职责
| 防护类型 | 主要能力 | 适合场景 |
|---|---|---|
| Web应用防火墙 | 拦截SQL注入、XSS等WEB攻击 | 网站、API接口有公网访问 |
| 主机安全 | 查杀木马、防御暴力破解 | 服务器操作系统层面 |
| 云防火墙 | 南北向、东西向流量控制 | 多VPC或混合云网络环境 |
网站安全防护哪家好没有标准答案，关键看你的部署位置，如果用户直连源站，WAF必须前置；如果攻击已进入内网，主机安全和流量审计更重要。
自建还是云托管：算清人力成本
自建安全组件需要专人维护规则库,更新慢，且容易误伤正常业务，相比之下，云托管WAF提供现成规则，支持按量付费和弹性扩容，降低了运维门槛。
企业网站安全防护价格从每年几百元到数万元不等，取决于域名数量、请求峰值和合规需求，创业公司早期可以用入门级WAF，把预算留给核心业务；政企客户则建议选择包含等保测评和日志留存的全套方案。
上线前必须过的三项检查：代码、配置、备份
代码层：第三方依赖和硬编码密钥
- 用OWASP Dependency-Check扫描第三方组件的高危漏洞。
- 用gitleaks或其他工具检查代码仓库是否泄露API密钥、数据库密码。
- 自查.git目录是否被Web目录收录，.env文件是否被部署排除。
配置层：环境差异导致的安全开关
- 确认生产环境关闭调试模式,不返回堆栈信息。
- 检查环境变量中的密钥是否与代码库同步更新。
- 清除测试接口和Mock数据。
备份层：备份可恢复才算有效备份
- 不仅要有自动化备份任务,还要定期做恢复演练。
- 备份文件与生产环境网络隔离,防止勒索病毒一起加密。
- 明确恢复时间目标,写在应急响应预案中。
上线后的持续监控同样是自检的一部分
日志与告警：出现问题第一秒知道
- 接入云日志服务,记录访问日志、操作日志和登录日志。
- 配置异常告警规则,如连续登录失败、上传webshell行为、外部访问敏感路径。
- 告警不是越多越好,关键要能独立处置，否则会被设为免打扰。
漏洞生命周期闭环：从发现到修复要记录
- 每月或每季度跑一次漏洞扫描,跟踪修复状态。
- 关注组件更新公告,高危漏洞补丁在一周内完成验证和部署。
- 重要业务上线后一周内做一次复测,确保上线前的整改没有引入新问题。
回到开头那句话：上线前自检不是一次性工作，而是一套习惯。 把检查项固化到发布流程中，每次发版都过一遍，成本和阻力反而最小，安全不是产品上线后的补丁，而是业务计划中的固定成本。
业务上线前安全自检常见问题解答
上线前自检需要多长时间？
小网站半天,复杂业务系统一周，主要取决于资产数量和接口复杂度，首次自检建议预留充足时间，因为要盘资产、测逻辑、修漏洞、复测，每一步都可能发现问题，上线后补一次检查，代价比上线前做高三倍以上。
没有专职安全人员，如何完成自检？
优先使用云厂商自带的安全中心、基线检查和漏洞扫描功能，把自动化能覆盖的部分跑完，再针对登录、支付、文件上传等核心业务，找第三方或熟悉安全开发的伙伴做一次手工渗透测试，多数安全工具都有免费版本或试用额度，足够支撑初次自检。
自检发现漏洞后，哪些必须修复才能上线？
高危和严重漏洞必须修复,包括SQL注入、命令执行、任意文件上传和垂直越权，中危漏洞可以上线后一周内修复，但要登记在缺陷库或任务看板上，写清楚风险接受理由和负责人，低危漏洞可以持续跟踪，不影响上线决策。