最直接做法是用 net/http 中间件统一拦截恶意请求，所有路径（含 /healthz、/Static/）均需经过，尽早执行并限制 body 大小防 oom。
用 net/http 中间件做请求特征过滤最直接
go 没有内置 WAF，但靠中间件机制能低成本拦截恶意请求。核心思路是：在 http.Handler 链上插一道检查逻辑，不满足规则就提前返回 403，不往下传。
常见错误是把过滤逻辑写在业务 handler 里——既难复用，又容易漏掉静态文件、健康检查等路径。应该统一收口到中间件。
- 所有请求必须经过中间件，包括
/healthz、/static/等路径（除非明确放行） - 中间件要尽早执行，比如放在日志、认证之前，避免无效请求触发后续逻辑
- 别用正则暴力匹配整个
r.URL.String()，注意 URL 解码差异：%2e%2e和..是等价的，但正则可能只匹配后者
func wafMiddleware(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { if isMaliciousRequest(r) { http.Error(w, "Forbidden", http.StatusForbidden) return } next.ServeHTTP(w, r) }) } isMaliciousRequest 该检查哪些特征
不是所有“奇怪”请求都要拦——重点防的是能导致 RCE、路径遍历、sql 注入、xss 反射的典型载荷。真实流量里大量误报来自扫描器和爬虫，得平衡安全与可用性。
以下特征建议默认启用，其他按需开启：
立即学习“go语言免费学习笔记（深入）”；
- URL 或
r.FormValue中含../、./、%2e%2e、%2f（路径遍历） - Header 如
User-Agent、Referer含sqlmap、nmap、dirbuster（工具指纹） - Query 或 Body 含典型注入关键词：
union select、sleep(、benchmark(（注意大小写和空格绕过） - cookie 值长度超 4KB 或含非 ASCII 控制字符（防 Cookie 注入）
别硬编码关键词列表——用 strings.Contains 效率低且易绕过；改用预编译的 regexp.Regexp，但注意正则回溯风险（比如 a+.*b 匹配超长字符串会卡住）。
用 io.LimitReader 防大 Body 拒绝服务攻击
WAF 不只是“看内容”，还要控资源。攻击者发一个 1GB 的 POST Body，你的 r.ParseForm() 或 io.ReadAll(r.Body) 可能直接 OOM。
正确做法是在中间件里限制读取上限，并早于业务逻辑生效：
- 对 json API，设
Content-Type: application/json的 Body 上限为 2MB - 对表单提交，用
r.ParseMultipartForm(32 限制 multipart 总大小 - 永远别用
io.ReadAll(r.Body)无限制读取，改用io.LimitReader(r.Body, maxBodySize)
注意：修改 r.Body 后，后续 handler 若再读会得到空内容。必须用 http.MaxBytesReader 替代手动包装，它会自动处理 Content-Length 校验和 413 错误。
上线前必须关掉 debug 模式并验证日志脱敏
本地开发时用 log.Printf 打印完整请求没问题，但生产环境一开就等于把攻击载荷全记进日志——尤其当 WAF 规则误判时，用户手机号、token 可能被原样记录。
两个关键动作不能省：
- 禁用所有
gin.DebugMode、echo.Debug类配置；用os.Setenv("GIN_MODE", "release")确保生效 - WAF 日志只记录 IP、时间、匹配的规则 ID、HTTP 状态码，绝对不记录
r.URL.RawQuery或r.Body内容 - 用
strings.ReplaceAll清洗Referer和User-Agent中的敏感字段（如 token=xxx），再写日志
最常被忽略的是：WAF 规则更新后没同步重启服务，或用了热重载但新规则未加载进内存——上线后跑个 curl -v "http://x/?a=../etc/passwd" 验证是否真拦截，比看文档靠谱得多。