微服务间通信必须启用tls双向认证，禁用纯http调用；gin中需强制验证对端证书链、校验jwt的aud字段、安全头中间件须置于最前且早于cors。
微服务间通信必须加 TLS + 双向认证
纯 HTTP 调用在微服务内部走通是常见但危险的做法——攻击者一旦突破任一节点，就能直接伪造请求调用其他服务。Gin 本身不提供服务间通信能力，但你用 http.Client 或 gRPC 调用下游时，必须强制启用 TLS，并验证对端证书。
关键点：
- 不要只校验
ServerName，要加载可信 CA 证书池并调用tls.Config.VerifyPeerCertificate验证证书链 - Gin handler 接收请求后，若需转发（如 API 网关场景），应剥离原始
Authorization头，改用短期 JWT 或服务间专用 token - 避免把开发环境的自签名证书硬编码进生产代码；用
os.Getenv("CA_CERT_PATH")动态挂载
JWT 校验不能只靠中间件解析，必须验签名+过期+aud
很多 Gin 项目用 github.com/appleboy/gin-jwt 或手写中间件解析 JWT，但漏掉 aud（受众）校验会导致 token 被跨服务复用——比如用户服务签发的 token 被订单服务错误接受。
实操建议：
- 使用
golang.org/x/oauth2/jws或github.com/golang-jwt/jwt/v5显式指定VerifyAudience(true)和ValidFunc自定义校验逻辑 -
aud值应为服务唯一标识（如"order-service"），而非泛用的"api" - 禁止在 Gin 的
c.Set("user_id", claims["sub"])后就认为鉴权完成——必须确保该sub在当前服务上下文中有对应权限记录
静态资源与 API 共享同一 Gin 实例时，安全头容易被覆盖
当你用 r.Static("/assets", "./public") 提供前端资源，又同时注册 JSON API 路由时，如果安全响应头中间件注册顺序不对，gin-contrib/cors 或自定义文件服务中间件可能覆盖你设的 X-Content-Type-Options 等头。
必须这么做：
- 安全头中间件
securityHeaders()要放在r.Use()最前面，且早于cors.New() - 对
Static路由，额外加一层 wrapper：r.GET("/assets/*filepath", func(c *gin.Context) { c.Header("X-Content-Type-Options", "nosniff") c.Header("Content-Security-Policy", "default-src 'self'") c.Next() }, gin.WrapH(http.FileServer(http.Dir("./public")))) - 别依赖
gin-contrib/static——它不支持 Header 注入，会绕过你的全局中间件
服务发现客户端未隔离导致凭证泄露
用 Consul/Etcd 做服务发现时，常见错误是把配置中心 client 初始化成全局变量，然后在 handler 里直接调用 client.KV().Get() 读取敏感配置（如数据库密码）。这会导致连接池复用、超时未设、错误日志暴露凭据路径。
正确姿势：
- 每个服务发现 client 必须绑定独立的
*http.Client，并设置Timeout: 3 * time.Second - 禁止在 handler 中同步调用 KV 查询——改用启动时预加载 + 定期刷新（如
time.Ticker），缓存到内存 map - 如果必须运行时查，用
context.WithTimeout(c.Request.Context(), 800*time.Millisecond)包裹调用，防止雪崩
最易被忽略的是：服务间调用链路中任意一环没做 aud 校验或没关 MIME sniffing，整个防御体系就形同虚设——不是“基本防护有了”，而是“某个头漏了，攻击面就全开”。
