go框架如gin默认不防xss和sql注入，因其仅负责路由分发，不干预数据处理；xss需html/template自动转义或csp头防护，sql注入须手动参数化查询，所有安全头（如csp、nosniff）及jwt签名验证等均需开发者显式实现。
Go语言常用框架本身不带默认安全加固，所有防御机制都得手动加——不设中间件、不配头、不验输入，就等于裸奔。
为什么 Gin/echo/fiber 默认不防 XSS 和 SQL 注入
这些框架只是 HTTP 路由和请求处理层，不干涉数据流向。比如 Gin.Context.BindJSON 会直接把 JSON 字段映射到结构体字段，但不会自动转义 HTML 或过滤脚本标签；db.Query 接收拼接的 SQL 字符串时，也不会拦住 ' OR 1=1 -- 这种输入。
- 框架只负责“把请求交给谁”，不负责“交给谁之前检查什么”
- SQL 注入防护必须靠
db.Prepare+ 参数化查询，不是框架能代劳的 - XSS 防护要靠输出编码（如用
html.EscapeString渲染模板），或前端 CSP 头限制执行 - 你用
echo.New()或gin.Default()启动服务时，Content-Security-Policy、X-Content-Type-Options这些头一个都不会自动加
三个必须手写的中间件：CSP、X-Frame-Options、nosniff
标准库 net/http 和主流框架都不内置安全响应头，漏掉任何一个都可能让浏览器降级执行恶意内容。
-
X-Content-Type-Options: nosniff—— 阻止浏览器根据响应体“猜” MIME 类型，避免.jpg里塞 JS 被当 script 执行 -
X-Frame-Options: DENY—— 禁止你的页面被嵌在别人 iframe 里，防点击劫持 -
Content-Security-Policy: default-src 'self'—— 最小权限起步，后续按需放开script-src或img-src - Gin 示例：
c.Header("Content-Security-Policy", "default-src 'self'")必须放在每个 handler 开头，或统一挂到gin.Use()
JWT 中间件里最容易忽略的两个校验点
很多项目只校验 token 是否存在、是否过期，却跳过了签名验证和 issuer 检查，导致伪造 token 直接通关。
- 没调用
token.Valid或等价方法（如jwt.Parse的第三个返回值）→ 签名无效的 token 也会被当成有效 - 没比对
token.Claims.(jwt.MapClaims)["iss"]→ 攻击者用另一个系统的 token 冒充你的用户 - 没设
time.Now().Add(3 * time.Hour)这类显式过期时间 → token 一旦签发就永久有效 - 别用
HS256+ 硬编码密钥写死在代码里；生产环境应从环境变量或 Vault 加载
静态文件服务的路径遍历漏洞怎么堵死
http.FileServer(http.Dir("./public")) 是高危操作，GET /..%2f..%2fetc%2fpasswd 可能直接读取宿主机敏感文件。
- 永远不要用
http.Dir直接暴露任意目录；改用http.FS+embed.FS（Go 1.16+）预编译白名单文件 - 若必须动态服务，先做路径规范化：
filepath.Clean(r.URL.Path)，再检查是否以允许前缀开头（如/static/） - 在中间件里拦截所有含
..或.env、.git的路径：strings.Contains(r.URL.Path, "..") || strings.HasPrefix(r.URL.Path, "/.") - Gin 用户注意：
engine.StaticFS("/static", http.Dir("./static"))不自带路径净化，仍需额外包装
真正危险的从来不是“不知道怎么加安全”，而是加了一半——比如加了 JWT 但忘了验签名，加了 CSP 但没关 unsafe-inline，加了 nosniff 却放任 fileserver 走原始 Dir。每道防线之间没有容错，断一环，整条链就失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
