做过Web开发的兄弟一定对这些攻击不陌生：
- 登录接口被注入SQL，数据库里的用户信息差点被拖走；
- 搜索框、评论区被插入恶意脚本，用户一打开页面就中招；
- 后台上传接口被利用，直接传了个Webshell上去，服务器差点被接管；
- API接口被恶意调用，参数被篡改，业务逻辑被绕过；
- 刚上线的新功能，还没等真实用户用上，就被攻击者扫出了漏洞。
这些攻击有一个共同特点：它们不是靠大流量压垮你，而是利用Web应用本身的逻辑漏洞、参数校验不严、接口暴露过多来“精准打击”。
DDoS防护解决的是“流量打满、业务不可用”的问题，Bot管理解决的是“爬虫、刷量、自动化攻击”的问题，而 WAF / Web应用防火墙 解决的是另一类更隐蔽、也更致命的问题——Web应用层攻击。
为了帮企业把Web应用的安全防护从“出了漏洞再补”变成“攻击进来前就拦住”，360CDN正式推出面向Web业务、API接口和核心业务系统的 WAF / Web应用防火墙方案。核心思路是：在CDN边缘侧对HTTP/HTTPS请求进行深度检测，识别SQL注入、XSS、命令注入、文件上传漏洞、Webshell、恶意扫描、异常参数篡改等攻击行为，把危险请求挡在源站之外。
别等漏洞被利用才想起来防护，WAF要前置到边缘
很多团队的Web安全思路还是“代码里做校验、服务器上装防护、出了事再查日志”。但现实是：
- 代码量越大，参数校验越容易遗漏；
- 业务迭代越快，新接口越容易忘记做安全加固；
- 第三方组件、开源框架、老系统，可能本身就存在已知漏洞；
- 攻击者扫描工具越来越自动化，你的漏洞可能比你更早被发现。
如果攻击请求已经打到源站，再在源站做防护，往往已经晚了。尤其是SQL注入、XSS、Webshell上传这类攻击，一旦成功，后果可能不是“页面报错”这么简单，而是 数据泄露、账号被盗、服务器被控、业务被篡改。
360CDN的WAF方案走的是 边缘检测 + 源站保护 的路线：
- 用户请求先到达CDN边缘节点；
- 边缘节点对请求URL、请求参数、请求头、请求体、Cookie、上传文件等内容进行检测；
- 正常请求继续转发到源站；
- 攻击请求、恶意扫描、异常参数、已知漏洞利用行为在边缘侧被识别并拦截；
- 源站只接收经过安全过滤后的正常业务流量。
简单说，就是把Web应用的安全防线从源站前移到边缘，让攻击请求在进入你的业务系统之前就被拦住。
SQL注入、XSS、Webshell，为什么是Web应用最常见的风险？
Web应用攻击看起来花样很多，但核心往往集中在几类高频风险上。
表格
这些攻击的共同点是：它们往往伪装成正常HTTP请求。
比如一个SQL注入请求，看起来可能只是一个普通的GET或POST请求；一个XSS攻击，可能只是评论里多了一段脚本；一个Webshell上传，可能只是文件上传接口里混进了一个恶意文件。
如果只靠简单规则或人工排查，很难在海量请求里及时发现。WAF的价值就在于：把这些“看起来像正常请求、实际带攻击意图”的流量识别出来。
360CDN WAF怎么做？“检测 + 拦截 + 运营”一套闭环
360CDN的WAF / Web应用防火墙方案，不是简单堆规则，而是围绕Web请求做一套持续防护机制。
1. 边缘检测：在请求进入源站前识别攻击
用户请求到达CDN边缘节点后，WAF会对请求进行多维度检测：
- URL路径是否异常；
- 请求参数是否包含SQL注入、XSS、命令注入等特征；
- 请求头、Cookie、User-Agent是否存在异常；
- 请求体是否包含恶意脚本或攻击Payload；
- 文件上传请求是否包含Webshell、脚本文件、异常后缀；
- 是否存在对后台路径、配置文件、敏感接口的恶意扫描；
- 是否存在参数篡改、越权访问、异常调用模式。
一旦识别到攻击行为，边缘节点可以直接拦截，不让请求进入源站。
这样做的好处很明显：
- 源站不用处理恶意请求；
- 业务代码压力下降；
- 漏洞被利用的概率降低；
- 安全事件响应更靠前。
2. 分级处置：观察、告警、拦截、阻断要分开
WAF最怕两种极端：
- 太松：攻击来了拦不住；
- 太严：正常请求被误拦，业务受影响。
360CDN的WAF方案强调分级处置：
- 正常请求：直接放行；
- 低风险异常：记录日志、持续观察；
- 中风险请求：告警、限速、增加验证；
- 高风险攻击：拦截、阻断；
- 已知漏洞利用：优先拦截并告警。
尤其是刚接入WAF时，不建议一上来就全部开启最严拦截。更稳妥的做法是：
- 先开观察模式，看真实业务请求长什么样；
- 识别误报风险；
- 对明确攻击开启拦截；
- 对敏感接口加强保护；
- 根据业务变化持续调整策略。
WAF不是“配置一次就完事”，而是需要结合业务持续运营。
3. 可视化运营：知道谁在攻击、攻击了什么、拦住了多少
很多团队上了WAF之后，只看“有没有拦截”，这还不够。
更关键的是要看清楚：
- 哪些域名、接口被攻击最多；
- 哪些地区、IP、请求特征异常集中；
- 攻击类型主要集中在SQL注入、XSS，还是恶意扫描；
- 是否存在针对新上线接口的探测；
- 是否存在反复攻击同一接口的行为；
- 拦截策略是否误伤了正常用户；
- 是否需要针对某个业务活动临时加强防护。
只有看得清，才能调得准。否则很容易出现“规则越来越多，误报也越来越多”的问题。
实战反馈：某SaaS平台后台频繁被扫描，WAF接入后恶意请求明显下降
前段时间，一个做SaaS产品的客户遇到一个很头疼的问题：他们的管理后台、API接口、用户数据查询接口，经常被外部工具扫描。
一开始他们以为只是普通访问，后来发现日志里有大量异常请求：
- 频繁访问
/admin、/login、/api/user、/config等路径； - 参数里夹杂SQL注入特征；
- 部分请求尝试上传异常文件；
- 有些请求明显是在探测后台入口和敏感接口；
- 还有一些请求试图绕过权限，直接访问内部接口。
这些请求单看某一个，可能不算“大流量”，但组合起来风险很高。一旦某个接口校验不严，就可能导致数据泄露或后台被入侵。
接入360CDN WAF / Web应用防火墙方案后，他们对核心域名和接口做了防护：
- 管理后台接口开启严格检测；
- 用户数据查询接口重点防护SQL注入和参数篡改；
- 文件上传接口加强Webshell和异常文件检测；
- 对恶意扫描、敏感路径探测进行拦截；
- 对正常业务请求保持低干扰放行。
接入后，他们反馈比较明显：
- 后台异常扫描请求明显减少；
- SQL注入、XSS等攻击请求在边缘侧被拦截；
- 源站日志里的恶意请求占比下降；
- 安全告警更集中，运维排查效率提高；
- 业务侧没有明显误伤；
- 团队对Web应用安全的可控感明显增强。
他们安全负责人后来总结：“以前看日志，一堆请求混在一起，很难分清哪些是正常访问，哪些是攻击。现在WAF在边缘先过滤了一层，源站压力小了，安全事件也更清晰了。”
⚠️ 掏心窝子的避坑指南
给准备上WAF的兄弟们提几个实战建议，都是很容易踩的坑。
1. 先梳理核心接口，别一上来就全站无差别防护
WAF不是全站一开就万事大吉。不同接口的风险等级不一样。
建议先梳理高价值、高风险接口：
- 登录接口；
- 注册接口；
- 找回密码接口；
- 后台管理接口；
- 用户数据查询接口；
- 订单接口；
- 支付接口；
- 文件上传接口；
- 搜索接口；
- 评论、留言、反馈接口；
- 内部API接口。
这些接口一旦被攻击，影响往往更大，应该优先纳入WAF保护范围。
普通静态页面如果防护过严，反而可能影响正常访问和SEO收录。
2. 刚接入WAF，先观察再拦截
很多团队一上WAF，就直接开启最严拦截模式，结果正常业务请求被误拦，用户反馈“页面打不开”“提交失败”“接口报错”。
更稳妥的做法是：
- 第一阶段：观察模式，先收集请求日志；
- 第二阶段：识别正常业务请求特征；
- 第三阶段：对明显攻击开启拦截；
- 第四阶段：对敏感接口加强策略；
- 第五阶段：大促、活动、新版本上线前提前加固。
WAF策略要跟着业务走，不能脱离业务场景盲目收紧。
3. 文件上传接口要重点防护
文件上传是Web应用里风险很高的功能。很多业务需要上传图片、文档、头像、附件，但如果校验不严，攻击者可能上传Webshell、脚本文件、可执行文件，甚至利用解析漏洞接管服务器。
建议重点防护：
- 文件后缀校验；
- 文件内容检测；
- 上传路径限制；
- 异常文件拦截；
- 上传接口访问频率限制；
- 上传后文件不要直接赋予执行权限；
- 对后台、管理端上传接口做更严格保护。
WAF能挡住一部分恶意上传，但业务侧也要做好文件校验和存储隔离。
4. API接口不能只防传统Web攻击
现在很多业务都是前后端分离，核心能力都通过API暴露。API攻击往往不只是SQL注入、XSS，还包括：
- 参数篡改；
- 越权访问；
- 接口滥用；
- 批量查询；
- 未授权访问；
- 敏感数据泄露；
- 异常调用频率。
所以WAF防护API时，不能只关注传统Web攻击特征，还要结合：
- 接口路径；
- 请求方法；
- 参数结构；
- 调用频率；
- 账号权限；
- 业务行为是否正常。
API越开放，越需要精细化防护。
5. WAF不是替代安全开发，而是多一层防线
WAF很重要，但不能把它当成“万能药”。
如果业务代码本身存在明显漏洞，比如：
- SQL拼接；
- 用户输入未校验；
- 文件上传无限制；
- 权限校验缺失；
- 敏感接口无鉴权；
- 错误信息暴露过多；
那WAF只能帮你挡住一部分攻击，不能从根本上解决问题。
更好的做法是：
- 开发阶段做好参数校验；
- 上线前做安全测试；
- 敏感接口做好鉴权；
- 日志不要暴露敏感信息；
- 用WAF做边缘防护和持续监控；
- 出现漏洞及时修复。
WAF是防线，不是替代品。
如果你的Web应用也面临 SQL注入、XSS、Webshell上传、后台被扫描、API被恶意调用、接口参数被篡改 这些问题，可以把核心域名和敏感接口接入360CDN WAF / Web应用防火墙方案，先做一轮请求检测和策略观察。
了解更多WAF与Web应用防护的实战玩法，请访问：360cdn.com