理解请求
规范化并解析路径、参数、请求体、方法、会话和客户端上下文，让策略能够基于应用层字段判断。
WAF 基础知识
什么是 WAF（Web 应用防火墙）？
Web 应用防火墙位于网站或 API 的请求路径上，在流量到达源站之前检查应用层上下文。有效的 WAF 体系不仅是一组规则，还包括正确的流量入口、可解释策略、正常业务验证、事件运营和经过演练的回滚路径。
快速结论
WAF 是面向 HTTP 与应用流量的安全控制
WAF 位于网站或 API 的请求路径上，解析 Host、URI、请求头、参数、Cookie 和请求体等 HTTP 上下文，再使用规则或行为信号决定放行、记录、挑战、限速或阻断。WAF 应与安全开发、身份认证、网络防火墙和监控协同使用，不能替代这些基础控制。
- 主要层级
- HTTP 与应用层流量
- 常见位置
- 边缘、反向代理、Ingress 或网关
- 推荐上线方式
- 先观察，再分阶段拦截
定义与边界
WAF 使用 Web 请求上下文做安全决策
传统包过滤通常判断地址、协议或端口是否允许，而 WAF 工作在更高层级。它会理解 HTTP 或 HTTPS 流量的结构和含义，例如请求路径、方法、请求头、Cookie、参数、请求体格式、响应上下文，以及产品能够识别的应用例外。
WAF 并不只代表一种产品形态。它可以是托管云服务、全球边缘控制、虚拟或硬件设备、反向代理、Ingress 集成，也可以是嵌入网关的规则引擎。共同目标是在 Web 流量进入应用代码之前进行应用感知检查与策略执行。
评估安全策略
根据产品能力执行托管规则、自定义规则、允许列表、限速、异常评分、信誉或行为信号。
执行可解释动作
放行、记录、计数、挑战、限速或阻断，同时保存足够证据用于调优、事件分析和回滚。
请求生命周期
WAF 从请求到响应的工作流程
不同产品的内部流水线并不相同，但一次可靠评估至少应能追踪以下阶段。TLS 必须在 WAF 能够看到预期 HTTP 上下文的位置终止，同时源站不能保留未受控制的旁路入口。
- 客户端流量
- 网络入口
- WAF 检测层
- 策略决策
- 放行到源站
- 阻断证据
接收并规范化流量
WAF 从边缘、代理、负载均衡、Ingress 或网关路径接收流量，并根据自身解析器和限制理解 HTTP 消息。
- 确认 TLS 与真实客户端身份处理。
- 测试编码路径、请求头、JSON、表单、上传和大请求体。
- 记录所有可能绕过检测的路径。
评估规则与信号
托管签名、自定义表达式、异常评分、限速条件、信誉和行为信号会按照产品特定顺序执行。
- 记录规则与规则集版本。
- 拆分托管规则、自定义规则、Bot 和限速变更。
- 例外必须限制到明确业务路径。
选择处理动作
匹配请求可能被记录、计数、挑战、延迟、限速或阻断；未匹配流量会通过已配置的源站路径转发给应用。
- 新控制尽量从观察模式开始。
- 验证阻断和挑战响应。
- 对比启用前后的延迟与错误行为。
保存证据与响应上下文
有效事件应标识请求字段、规则或信号、动作、应用路径、上游结果和必要客户端上下文，同时避免记录不必要的敏感数据。
- 测试日志投递和保留。
- 将事件接入告警和响应流程。
- 演练规则停用或 WAF 路径回退。
架构选择
WAF 的主要部署类型
部署形态决定谁负责 DNS、TLS、扩缩容、升级、日志、故障处理和紧急回滚。规则功能相近的产品也可能带来完全不同的运营模型。
托管云端或边缘 WAF
在厂商边缘或云交付路径检查流量，通常便于全球扩展和使用托管规则，但 DNS、路由、套餐限制、日志、支持和源站旁路都必须纳入决策。
云原生资源绑定
WAF 策略关联到受支持的负载均衡、CDN、API 或应用交付资源，适合云原生工作负载，同时会继承该云的作用域、区域、日志和计费模型。
自托管反向代理或设备
团队在源站或网络边界附近运行检测层，可以获得直接控制并支持私有环境，但容量、补丁、高可用和规则运营都成为本地责任。
Ingress、网关或嵌入式引擎
检测运行在 Kubernetes Ingress、API 网关、服务代理或应用交付代码中，便于贴近工程流程，但必须验证连接器、解析器、升级和责任边界。
防护范围
WAF 可以帮助检测或控制什么
实际覆盖取决于产品、规则集、可见字段、请求体限制、协议支持和调优结果。功能名称本身不能证明某个具体业务已经受到保护。
常见 WAF 使用场景
- 检测与 SQL 注入、跨站脚本、命令注入、路径遍历、文件包含等应用层攻击相关的请求模式。
- 在应用代码修复期间实施虚拟补丁，前提是能够安全描述漏洞路径和请求特征。
- 在平台能力允许时，对登录滥用、爬虫、暴力破解、库存抢购或 API 高频流量执行限速或挑战。
- 按照明确策略限制方法、路径、地区、IP 范围、请求头、请求体格式或已知恶意客户端。
- 生成可用于调查可疑请求、分析攻击趋势和推动应用修复的安全事件。
声称具备防护前需要的证据
- WAF 能看到应用实际使用的 Host、路径、客户端身份、方法、请求头和请求体。
- 请求体与文件上传限制覆盖受保护业务。
- 托管规则和自定义规则使用预期版本与模式。
- 登录、上传、API、后台、健康检查和大请求体流程已经验证。
- 事件可以查询，每个例外都有责任人、原因、范围和复核日期。
安全边界
WAF 不能替代什么
WAF 只能降低应用攻击面的一部分，不能证明应用本身安全，也不应成为推迟代码修复、访问控制、资产盘点或事件响应的理由。
安全设计与代码修复
业务逻辑滥用、越权、不安全流程、密钥泄露和依赖漏洞通常需要修改代码、架构、身份体系或研发流程，而不是增加请求过滤规则。
网络与主机安全
WAF 不是主机防火墙、终端安全、补丁系统、网络分段策略，也不能替代覆盖所有层级的网络防火墙和 DDoS 防护。
完整 API 发现与授权
部分现代平台加入 API 发现和 Schema 执行，但基础 WAF 不会自动理解所有 API、对象级授权、敏感数据流或已经遗忘的接口。
无需调优的自动防护
宽泛规则可能误拦正常业务，过窄规则又可能漏报。解析器差异、编码、例外、规则顺序和应用变更都需要持续测试。
控制边界
WAF 与防火墙、CDN、API 网关和 RASP 的区别
这些控制可以同时存在。真正需要判断的是哪一层拥有完成某项决策所需的上下文和责任，而不是哪个缩写能够替代所有安全控制。
| 控制 | 主要范围 | 典型位置 | 核心区别 |
|---|---|---|---|
| Web 应用防火墙 | HTTP 网站与 API | 边缘、反向代理、Ingress、网关或云资源绑定 | 理解应用层请求上下文并执行 Web 安全策略。 |
| 网络防火墙或 NGFW | 网络、主机、服务、协议和连接 | 网络边界、分段边界、云网络或主机 | 控制更广泛的网络访问；即使具备应用识别，也不自动替代针对工作负载的 WAF 检测。 |
| CDN 或边缘交付 | 内容交付、缓存、可用性和边缘路由 | 源站之前的全球边缘 | 负责内容传输和缓存。CDN 可以集成 WAF，但 CDN 本身不等于应用安全策略。 |
| API 网关 | API 路由、认证集成、配额和转换 | API 入口 | 负责 API 管理并可能执行 Schema 或限速；部分网关嵌入 WAF，但两类责任仍需分别验证。 |
| RASP | 应用运行时内部行为 | 应用进程或运行时 | 使用应用内部执行上下文，而 WAF 通常在请求进入应用代码之前做判断。 |
技术演进
Web 应用防火墙的发展历史
理解 WAF 历史时，更适合把它看作应用感知过滤能力的持续演进，而不是寻找唯一发明日期。随着 Web 应用、HTTPS、云交付、API 和自动化变化，产品术语与部署方式也不断变化。
- 1990 年代
应用代理与 HTTP 感知过滤
代理网关和应用层过滤器开始使用比基础包过滤更丰富的协议上下文做决策，为后来的 WAF 产品建立了架构基础。
- 2000 年代初
商业 WAF 与开源 ModSecurity
商业应用防火墙逐渐形成产品类别；ModSecurity 于 2002 年首次发布，让 Apache 用户及后续连接器生态能够使用开源 HTTP 检测引擎。
- 2000 年代后期
合规推动规模化采用
支付卡安全要求提升了业界对公开 Web 应用代码审查和自动化技术控制的关注，WAF 逐渐进入合规与虚拟补丁方案。
- 2010 年代
云端、CDN 与托管 WAF
WAF 能力进入全球边缘网络、云负载均衡和托管服务，团队不再只能依赖本地设备，也可以直接消费托管规则和弹性容量。
- 2010 年代后期
API、Bot、信号与 WAAP
现代应用防护逐渐把 WAF 策略与 API 安全、Bot 管理、DDoS 缓解、客户端信号和安全分析组合到更广泛的 Web Application and API Protection 平台中。
- 2020 年代
多云、Kubernetes、自动化与行为分析
WAF 策略分布在边缘服务、云资源、Kubernetes Ingress、网关和自托管引擎中。自动化与行为分析持续发展，但流量可见性、误报、责任和回滚仍是核心工程问题。
不同厂商对历史产品的名称并不一致。具体的“第一款产品”和发布日期应作为独立资料研究问题，优先使用项目档案、标准组织和同期文档，而不是反复引用营销时间线。
生产运营
WAF 是持续运营流程，不是一次性开关
WAF 的长期价值取决于团队能否安全观察流量、解释决策、维护例外、更新规则并从错误中快速恢复。
绘制真实流量路径
记录 DNS、TLS 终止、CDN 或负载均衡、WAF 绑定、源站、健康检查、客户端身份和所有旁路路径。
- 明确每一层责任人。
- 确认源站拒绝未授权旁路。
- 部署变更必须附带流量图。
建立正常业务基线
在提升拦截强度前捕获代表性正常流量，以便把误报定位到路径、参数、规则或请求体特征。
- 覆盖登录、上传、API、后台和移动客户端。
- 记录正常状态码与延迟。
- 测试大请求和少见但合法的请求。
先观察，再扩大拦截
优先使用 Count、Detection、Preview 或只记录模式，再把低风险、可解释的控制按小批次转为 Prevention。
- 一次只修改一类策略。
- 审查高频匹配。
- 确认阻断事件进入正确运营队列。
管理例外与策略漂移
每个例外应记录规则、字段、路径、业务原因、责任人和复核日期；应用发布与规则更新都可能使旧假设失效。
- 不要为局部问题创建全局例外。
- 定期复核过期例外。
- 对策略和规则优先级进行版本管理。
演练回滚与事件响应
团队应知道如何停用规则、退回观察模式、解除资源关联或恢复旧流量路径，同时保留解释事件所需证据。
- 在受控环境计时回滚。
- 记录紧急授权人。
- 保留规则、请求字段和上游结果日志。
选型检查点
我们是否需要 WAF？
当公开网站或 API 拥有稳定检测入口，并且组织具备规则与事件运营能力时，WAF 最有价值。如果只是为满足检查项而部署，却没有流量责任、调优和响应能力，收益通常很低。
值得评估 WAF 的常见原因
- 公开网站或 API 具有明确边缘、代理、负载均衡、Ingress 或网关路径。
- 团队需要托管规则、虚拟补丁、限速或应用层事件证据。
- 应用无法立即全部修复，需要在修复期间增加补偿控制。
- 合规、客户保障或事件响应需要可记录的 Web 防护层。
- 组织可以明确策略、例外、日志、测试和回滚责任人。
选择产品前必须回答的问题
- 流量当前从哪里进入，源站是否可以绕过 WAF 访问？
- 需要检查哪些协议、方法、请求体、文件上传和 API？
- 谁负责 DNS、TLS、规则、例外、告警、更新、容量和紧急回滚？
- 请求量、日志量、支持等级和可选能力如何影响完整成本？
- 能否使用同一套正常业务、安全测试和证据包公平比较候选产品？
常见问题
WAF 和普通防火墙一样吗？
不一样。WAF 使用应用层上下文保护 HTTP 网站和 API；网络防火墙与 NGFW 控制更广泛的网络、主机、服务和协议访问。实际环境通常需要两者协同。
WAF 能防住所有 OWASP Top 10 风险吗？
不能。WAF 可以帮助处理部分常见 Web 攻击请求模式，但效果依赖流量可见性、规则、限制和调优。越权、业务逻辑、不安全设计、依赖漏洞和身份问题通常必须修改应用或架构。
WAF 应该一开始就开启阻断吗？
不建议对未经测试的应用直接全面阻断。应从受控路径或观察模式开始，验证正常业务、调优窄范围例外、确认日志与回滚，再分阶段启用拦截。
CDN 可以自带 WAF 吗？
可以。很多边缘与 CDN 平台集成 WAF。CDN 负责交付与缓存，WAF 组件负责应用安全策略；套餐限制、日志、路由和源站旁路仍需分别验证。
WAAP 是什么？
Web Application and API Protection 是更广泛的产品类别，可能组合 WAF、API 安全、Bot 管理、DDoS 缓解、客户端信号和分析能力。不同厂商打包差异很大，应评估实际可用控制和证据。