做过Web应用、电商交易、SaaS平台、企业官网、API接口的团队，大概率都遇到过这些场景：
- 全站HTTPS已经配好，但网站还是被SQL注入攻击，数据库差点被拖库；
- 用户提交的表单被XSS攻击，页面里被注入了恶意脚本；
- 竞争对手或恶意用户用爬虫疯狂抓取数据，源站带宽被打满；
- 某个接口被刷，短时间内请求量暴增，服务直接被打挂；
- 网站被挂了木马，用户访问时被跳转到博彩、色情页面；
- 日志里全是异常请求，但分不清哪些是攻击、哪些是正常流量；
- 安全团队说要上WAF，但不知道WAF到底能防什么、怎么选。
这些问题背后，指向同一个核心：HTTPS只解决传输加密，防不住应用层攻击。
HTTPS通过TLS/SSL加密，保障的是"数据在传输过程中不被窃听和篡改"。但攻击者如果直接发起SQL注入、XSS、命令执行、文件包含、路径遍历等应用层攻击，HTTPS是防不住的——因为请求本身就是"合法"的HTTPS请求，只是内容里藏着恶意代码。
为了帮企业补上应用层安全这块短板，360CDN正式推出面向Web业务、API接口和核心业务系统的 Web应用防火墙 WAF方案。核心思路是：在CDN边缘侧部署WAF引擎，对所有进入的请求进行实时检测和过滤，把恶意攻击拦截在边缘，保护源站和业务数据安全。
HTTPS ≠ 应用安全：为什么有了HTTPS还需要WAF？
很多团队有一个误区：网站配了HTTPS，地址栏有小锁，就安全了。
实际上，HTTPS和WAF解决的是不同层面的问题：
表格
简单说：
- HTTPS解决的是"数据怎么传"的问题——确保传输过程中不被窃听和篡改；
- WAF解决的是"请求是什么"的问题——确保进入系统的请求是合法的，不是恶意攻击。
两者是互补关系，不是替代关系。
只有HTTPS没有WAF，就像给房子装了防盗门，但窗户没关——攻击者可以从应用层直接打进来。
360CDN WAF怎么做？"边缘检测 + 智能规则 + 实时拦截"
360CDN的WAF方案，不是简单地在源站前面加一个防火墙，而是把WAF引擎部署在CDN边缘节点上，在请求到达源站之前就完成检测和拦截。
1. 边缘检测：攻击在离用户最近的地方被拦截
传统WAF通常部署在源站前面或机房入口，攻击请求需要先到达机房，再被WAF检测。
360CDN的WAF部署在边缘节点上：
- 用户请求到达边缘节点；
- WAF引擎实时检测请求内容（URL、参数、Header、Body）；
- 如果判定为恶意攻击，直接在边缘拦截并返回阻断响应；
- 如果是正常请求，才转发到源站。
这样做的好处是：
- 攻击流量在边缘被拦截，不会到达源站；
- 源站不用消耗资源处理恶意请求；
- 边缘节点分布式部署，天然具备抗大流量攻击的能力；
- 拦截响应从边缘直接返回，延迟低。
2. 智能规则：覆盖主流Web攻击类型
WAF的核心是检测规则。360CDN WAF内置了丰富的规则库，覆盖主流Web攻击类型：
- SQL注入：检测URL、参数、Body中的SQL注入攻击，防止数据库被拖库；
- XSS跨站脚本：检测页面注入的恶意脚本，防止用户被钓鱼或劫持；
- 命令执行/代码执行：检测系统命令注入、代码执行攻击；
- 文件包含/路径遍历：检测非法文件读取、目录遍历攻击；
- CSRF跨站请求伪造：检测伪造的用户请求；
- SSRF服务器端请求伪造：检测服务端发起的恶意请求；
- XML外部实体注入（XXE）：检测XML解析漏洞利用；
- 反序列化漏洞：检测Java、PHP等反序列化攻击；
- 已知漏洞利用：覆盖主流CMS、框架、中间件的已知漏洞；
- Bot管理：识别和拦截恶意爬虫、刷量工具、自动化攻击脚本。
规则库持续更新，及时覆盖新披露的漏洞和攻击手法。
3. 实时拦截：从"事后补救"变成"事前防御"
没有WAF的情况下，攻击往往是这样发生的：
- 攻击者发起SQL注入或XSS攻击；
- 请求到达源站，被应用处理；
- 攻击成功，数据泄露或页面被篡改；
- 安全团队通过日志发现异常；
- 紧急修复漏洞、清理后门、恢复数据。
这个过程是"事后补救"，损失已经造成。
有了WAF之后：
- 攻击者发起攻击；
- 请求到达边缘节点，WAF实时检测；
- 判定为恶意攻击，直接拦截；
- 攻击请求不会到达源站；
- 安全团队通过WAF日志了解攻击情况，持续优化规则。
这个过程是"事前防御"，攻击在到达源站之前就被挡在外面。
哪些业务场景最需要WAF？
几乎所有Web业务都需要WAF，但在以下场景中，WAF的价值尤其突出：
表格
共同特点是：业务涉及用户数据、交易安全、品牌声誉，一旦被攻击，影响面大、损失严重。
实战反馈：某电商平台SQL注入和CC攻击频发，接入WAF后攻击拦截率99%+
前段时间，一个电商平台客户遇到一个很棘手的问题：他们的网站经常遭受SQL注入攻击，攻击者试图通过注入获取用户数据和订单信息；同时还有CC攻击，高峰期请求量暴增，源站服务频繁被打挂。
运维团队面临的痛点很明确：
- SQL注入攻击频繁，靠代码层修复漏洞来不及，总有漏网之鱼；
- CC攻击时源站CPU和带宽被打满，正常用户无法访问；
- 日志里全是异常请求，但人工分析效率低，无法实时响应；
- 安全团队人手有限，无法7×24小时盯着攻击；
- 之前尝试过开源WAF，但规则更新慢，误报率高，维护成本高。
接入360CDN WAF方案后，他们做了以下调整：
- 开启SQL注入、XSS、命令执行等核心规则集；
- 开启CC防护，设置频率阈值，自动拦截高频恶意IP；
- 开启Bot管理，识别和拦截恶意爬虫；
- 配置自定义规则，针对业务特点做精细化防护；
- 开启WAF日志和告警，实时监控攻击情况；
- 对误报请求做白名单调整，优化规则准确率。
接入后，他们反馈比较明显：
- SQL注入攻击拦截率99%+，数据库安全风险大幅降低；
- CC攻击时WAF自动拦截恶意IP，源站服务稳定；
- 恶意爬虫被有效识别和拦截，数据抓取行为明显减少；
- WAF日志清晰展示攻击来源、攻击类型、攻击频率，安全团队可以快速响应；
- 误报率经过调优后降到很低，正常用户访问不受影响；
- 运维团队不用半夜被攻击告警叫醒，WAF自动拦截大部分攻击。
他们安全负责人后来总结："以前靠代码层防SQL注入，修了一个漏洞又冒出来另一个。上了WAF之后，大部分攻击在边缘就被拦住了，源站压力小了很多，安全团队也能更专注于核心业务安全。"
⚠️ 掏心窝子的避坑指南
给准备上WAF的兄弟们提几个实战建议，都是很容易踩的坑。
1. WAF不是"开了就完事"，需要持续调优
WAF开启后，初期可能会有误报——把正常请求当成攻击拦截了。
建议：
- 上线初期先开启"观察模式"或"只记录不拦截"，分析日志；
- 确认规则准确率后，再切换到"拦截模式"；
- 对误报的请求做白名单调整；
- 定期 review WAF日志，优化规则；
- 业务迭代时，同步检查WAF规则是否需要调整。
WAF是一个需要持续运营的安全组件，不是一劳永逸的。
2. 不要只依赖WAF，代码层安全同样重要
WAF是应用层的一道防线，但不能替代代码层安全。
如果代码存在严重漏洞，攻击者可能通过以下方式绕过WAF：
- 使用WAF规则未覆盖的攻击变种；
- 利用业务逻辑漏洞（WAF通常不检测业务逻辑）；
- 通过加密或编码绕过检测；
- 利用0day漏洞（规则库尚未覆盖）。
建议：
- WAF作为第一道防线，拦截大部分已知攻击；
- 代码层做好参数校验、SQL预编译、XSS过滤；
- 定期做代码审计和漏洞扫描；
- 对核心业务做渗透测试；
- WAF + 代码安全 + 定期审计，多层防护。
WAF是"安全网"，不是"万能药"。
3. CC防护阈值要合理设置
CC防护通过频率限制拦截恶意请求，但阈值设置不当会影响正常用户。
建议：
- 根据业务正常流量设置合理的频率阈值；
- 区分API接口和页面请求，设置不同的阈值；
- 对登录、注册、搜索等高频接口单独设置规则；
- 开启IP信誉库，优先拦截已知恶意IP；
- 结合人机验证（验证码）做二次确认，减少误伤。
阈值太松防不住攻击，太严会误伤正常用户，需要找到平衡点。
4. API接口要单独防护
API接口和Web页面的攻击面不同，WAF规则需要针对性配置。
建议：
- 对API接口开启参数检测（JSON、XML、Form参数）；
- 设置API频率限制，防止接口被刷；
- 对敏感接口（登录、支付、修改密码）加强防护；
- 开启Bot管理，识别自动化脚本调用；
- 对API版本做管理，旧版本接口及时下线或加强防护。
API接口通常没有前端页面，攻击更隐蔽，需要特别关注。
5. WAF日志要定期分析
WAF日志是了解攻击情况、优化规则的重要依据。
建议：
- 定期查看WAF日志，了解攻击类型和来源；
- 对高频攻击IP做封禁；
- 对误报请求做白名单调整；
- 关注新出现的攻击手法，及时更新规则；
- 将WAF日志接入SIEM或安全运营平台，做关联分析。
不看日志的WAF，相当于"开了但不知道有没有用"。
如果你的业务也面临 SQL注入/XSS攻击频繁、CC攻击打挂服务、恶意爬虫抓取数据、API接口被刷、安全合规要求高 这些问题，可以把核心Web业务和API接口接入360CDN WAF方案，先做一轮攻击面梳理和规则调优。
了解更多WAF的实战玩法，请访问：360cdn.com