网站漏洞扫描不是装个工具每周跑一次就完事，真正有效的做法是把扫描嵌入发布流程。每次代码合并到主干前，用自动化扫描跑一遍依赖库和静态代码，能在漏洞进入生产环境前拦下七成以上的常见问题。扫描结果要分级处理，高危漏洞必须在24小时内修复或回滚，中危漏洞进入迭代排期，低危漏洞记录在案并设置复查周期。很多企业的问题不是没扫描，而是扫描报告没人看、没人跟，最后变成合规摆设。
SQL注入依然是企业网站最危险的漏洞类型之一。防护的核心原则是参数化查询，所有用户输入必须通过预编译语句绑定变量，而不是拼接字符串。以Java的JDBC PreparedStatement为例：
String sql = "SELECT * FROM users WHERE username = ? AND status = ?"; PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setString(1, username); pstmt.setInt(2, 1); ResultSet rs = pstmt.executeQuery();
如果项目中有历史遗留的拼接SQL，应优先改造为参数化形式。对于无法立即改造的场景，必须对输入做严格的类型校验和白名单过滤，同时限制数据库账号权限，禁止Web应用使用管理员账号连接数据库。存储过程不能替代参数化查询，如果存储过程内部仍然拼接SQL，同样存在注入风险。
跨站脚本攻击（XSS）的防护重点在输出端。所有从用户输入或第三方接口获取的数据，在输出到HTML页面时必须做上下文相关的编码。HTML标签内容使用HTML实体编码，属性值使用属性编码，JavaScript上下文使用JavaScript编码，URL参数使用URL编码。前端框架如React和Vue默认对插值表达式做了转义，但使用v-html或dangerouslySetInnerHTML时仍然存在风险。企业应建立统一的输出编码函数库，禁止开发人员自行处理转义逻辑。
跨站请求伪造（CSRF）的防护需要结合多种手段。服务端生成随机的CSRF Token并绑定到用户会话，前端在每次状态变更请求中携带该Token，服务端校验通过后才执行操作。对于前后端分离架构，可以使用双重提交Cookie方案：服务端在登录时下发一个随机值写入Cookie，前端JavaScript读取该值并放入自定义请求头，服务端校验请求头和Cookie中的值是否一致。关键操作如修改密码、转账、删除数据，应额外要求二次验证。
文件上传漏洞的防护不能只检查文件扩展名。攻击者可以伪造Content-Type头，也可以把可执行代码嵌入图片文件中。有效的做法包括：服务端检查文件内容而非客户端可控制的元数据，使用白名单限制允许的文件类型，对上传文件重命名并存储到非Web可执行目录，限制上传目录的脚本执行权限，对图片文件进行二次渲染或压缩以消除嵌入的恶意代码。如果业务允许，将文件存储到对象存储服务并配合CDN分发，可以进一步隔离风险。
暴力破解攻击的防护策略需要平衡安全性和用户体验。针对登录接口，应实现基于账号和IP的双维度限流，同一账号连续失败5次后锁定15分钟，同一IP在一分钟内请求超过20次则触发验证码或临时封禁。验证码应使用行为式验证或滑动验证，传统图形验证码的识别率已经很高。对于高价值账号，应强制启用双因素认证。登录接口的响应信息要统一，不能通过错误提示判断用户名是否存在。
DDoS攻击的防护需要分层部署。网络层攻击依靠上游运营商或云服务商的流量清洗能力，企业应确保核心域名使用高防IP或接入DDoS防护服务。应用层攻击如CC攻击，需要在Web服务器或网关层做频率限制和行为分析。Nginx的limit_req模块可以限制单IP的请求速率，但面对分布式攻击需要结合IP信誉库和智能识别算法。关键业务应设计降级方案，在遭受攻击时优先保证核心功能的可用性，非核心功能可以临时关闭。
HTTPS配置是网站安全的基础，但配置不当反而会带来隐患。启用HTTPS后必须同时配置HSTS头，强制浏览器使用加密连接，防止降级攻击。TLS协议版本至少使用1.2，推荐1.3，禁用SSLv2、SSLv3和TLS 1.0。证书私钥要妥善保管，使用硬件安全模块或密钥管理服务存储，不要在代码仓库或服务器明文存放。证书到期前30天应触发自动续期或告警，避免因证书过期导致服务中断。
服务器系统层面的加固同样重要。SSH登录应禁用密码认证，改用密钥认证，并修改默认端口或使用跳板机隔离。防火墙默认拒绝所有入站流量，仅开放业务必需的端口。系统补丁应建立定期更新机制，高危漏洞补丁在发布后48小时内完成测试和部署。应用运行账号应遵循最小权限原则，禁止使用root或管理员权限运行Web服务。日志必须集中收集并设置保留周期，关键日志如登录记录、操作审计日志至少保留6个月。
Web应用防火墙（WAF）是重要的防护层，但不能完全依赖。WAF的规则库需要持续更新，并针对业务特点做自定义规则调优。上线新功能时，应在WAF的检测模式下运行一段时间，观察误报情况后再切换到拦截模式。WAF的绕过技术不断演进，分块传输、编码变形、协议混淆等手段都可能绕过规则检测，因此WAF必须与应用层防护措施配合使用，不能替代代码层面的安全修复。
安全监控和应急响应能力决定了一家企业在遭受攻击后的恢复速度。企业应部署入侵检测系统，对异常流量、异常登录、异常文件变更进行实时告警。建立安全事件分级响应流程，明确不同级别事件的响应时限、责任人和上报路径。定期进行应急演练，模拟勒索软件、数据泄露、网站篡改等场景，检验团队的响应能力和预案的有效性。备份策略要执行3-2-1原则：至少3份数据副本，存储在2种不同介质上，其中1份在异地。备份数据要定期做恢复测试，确保在真正需要时能够成功恢复。
第三方组件和依赖库的安全管理经常被忽视。现代Web应用大量使用开源组件，一个底层依赖的漏洞可能影响整个系统。企业应建立软件物料清单（SBOM），记录所有直接和间接依赖的版本信息。使用自动化工具持续监测依赖库的已知漏洞，发现高危漏洞后评估影响范围并及时升级。对于不再维护的开源项目，应评估替代方案或自行维护分支。引入新组件前进行安全评估，避免引入不必要的攻击面。
安全意识的培训要面向全员而非仅限技术团队。钓鱼邮件仍然是攻击者获取凭据的主要手段之一，应定期进行模拟钓鱼测试，对点击恶意链接的员工进行针对性教育。运维和开发人员需要掌握安全编码规范，了解常见漏洞的原理和修复方法。管理层需要理解安全投入的必要性，将安全指标纳入项目考核体系。安全不是某一个团队的责任，而是贯穿需求、设计、开发、测试、运维全流程的基础要求。
