Go实现WAF的核心是将过滤逻辑嵌入标准http.Handler链，通过中间件式Handler包装原始handler，在轻量检查后放行；需注意双重编码解码、代理头可信解析、body流控制及白名单优先等关键细节。
直接检测恶意访问不能靠“拦截所有可疑请求”这种模糊逻辑，而必须聚焦具体攻击面：高频扫描、非法 User-Agent、异常请求头、重复无意义路径、未授权的原始 body 读取行为。Echo 中间件本身不带 WAF 能力，得自己写规则链，且顺序和 body 读取时机稍错就会失效。
如何用中间件识别高频扫描行为
真实攻击者常使用工具（如 dirsearch、gobuster）暴力探测 /admin、/backup、/.git 等路径，特征是短时间大量 404 请求，且 User-Agent 固定或为空。
- 用
sync.Map或外部缓存（如 Redis）记录 IP + 路径前缀（如/admin）的 1 分钟内请求数，超阈值（如 10 次）即返回 429 - 别只看
c.Request().RemoteAddr，要先解析 X-Forwarded-For（但需校验前置代理可信，否则可伪造） - 避免在中间件里做耗时操作，计数器更新建议用原子操作或带 TTL 的缓存，否则并发高时成为瓶颈
- 注意：/favicon.ico、/robots.txt 这类默认请求容易被误判，建议白名单放过
为什么不能依赖 c.FormValue 或 c.QueryParam 做 UA 校验
因为 c.FormValue 和 c.QueryParam 会触发自动解析——前者会消费 Request.Body，后者会解码 URL，一旦你在验签或防重放中间件之前调用了它们，后续再读原始 body 就会得到空字节或 http: read on closed response body 错误。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- UA 校验应只读
c.Request().Header.Get("User-Agent")，不碰 body 和 query - 若需同时校验签名和 UA，中间件顺序必须是：UA 检查 → 原始 body 读取（
io.ReadAll(c.Request().Body)）→ 签名校验 → 业务处理 - 微信回调要求返回纯字符串
fail，支付宝回调要求返回success，这些响应体不能被任何中间件覆盖或包装
如何防止中间件被绕过导致原始 body 泄露
攻击者可能故意构造畸形请求（如 Content-Type 错误、body 超长、chunked 编码异常），诱使中间件 panic 或跳过校验，让后续 handler 直接处理未过滤数据。
- 在读原始 body 前强制校验
c.Request().ContentLength，超限（如 >5MB）直接c.String(400, "bad request") - 对
Content-Type做白名单：仅允许application/xml（微信）、application/x-www-form-urlencoded（支付宝）、application/json（自定义回调），其余一律拒收 - 用
http.MaxBytesReader包裹c.Request().Body，防止 OOM 攻击 - 所有中间件必须用
defer func() { if r := recover(); r != nil { c.String(500, "internal error") } }()包一层，避免 panic 泄露堆栈
真正难的不是写规则，而是确保每条规则都在正确时机生效——比如 UA 检查不能放在 body 读取之后，验签不能复用已被解析过的 FormValue，而所有错误响应都得严格匹配第三方平台文档要求的字符串格式。漏掉任意一环，防御就形同虚设。
