应手动清除或覆盖Server头、使用html/template自动转义防XSS、SQL查询用参数化、设置X-Content-Type-Options/nosniff等安全头、Cookie设HttpOnly/Secure/SameSite属性。
如何防止 Go HTTP 服务暴露敏感头信息
默认情况下，net/http 会返回 Server: Go-http-client/1.1 或类似标识，攻击者可据此判断后端技术栈。这不是漏洞本身，但属于信息泄露风险。
- 必须在所有
http.ResponseWriter响应前手动清除或覆盖Server头：使用w.Header().Set("Server", "")或设为空字符串 - 禁用默认的
Date和Content-Length头不现实，但可通过中间件统一移除非必要头，如X-Powered-By、X-AspNet-Version（虽 Go 不自带，但避免被其他代理注入） - 注意：若使用
gin或echo，它们默认不设Server头，但某些版本曾因底层http.Server配置未关闭而泄露——需检查http.Server{WriteTimeout, ReadTimeout, IdleTimeout}等字段是否显式配置，避免依赖默认值
Go 中正确处理用户输入以防御 XSS 和 SQL 注入
Go 没有“魔法引号”或自动转义机制，所有输出和拼接都需开发者主动防护。模板渲染和数据库查询是两个高危场景。
- HTML 输出必须用
html/template（而非text/template），它会自动对.Name等字段做上下文敏感转义；若需插入可信 HTML，请显式调用template.HTML(...) - SQL 查询严禁字符串拼接。始终使用
db.Query或db.Exec的参数化方式：db.Query("SELECT * FROM users WHERE id = $1 AND status = $2", userID, "active")，$1/$2 是 PostgreSQL 占位符；MySQL 用?，SQLite 同样支持 - 路径参数（如
/user/:id）需校验格式：用strconv.ParseInt(id, 10, 64)替代直接转int，失败即返回http.StatusBadRequest
使用 Go 标准库设置安全 HTTP 头
Go 不内置安全头中间件，必须手动添加。关键头包括 Content-Security-Policy、Strict-Transport-Security、X-Content-Type-Options 等。
-
X-Content-Type-Options: nosniff可防止 MIME 类型嗅探，只需在响应头中写入：w.Header().Set("X-Content-Type-Options", "nosniff") -
Strict-Transport-Security必须只在 HTTPS 下发送，且不能用于本地开发（localhost）：if r.TLS != nil { w.Header().Set("Strict-Transport-Security", "max-age=31536000; includeSubDomains") } -
Content-Security-Policy推荐从严格策略起步，例如"default-src 'self'; script-src 'self' 'unsafe-inline'"—— 注意：Go 模板内联 JS 若含onclick或，需明确允许'unsafe-inline'或改用事件委托 + 外链
Go Web 服务中 TLS 和 Cookie 安全配置要点
很多团队用反向代理（如 Nginx）终止 TLS，导致 Go 应用层忽略安全配置，但 Cookie 属性、重定向逻辑仍需应用层控制。
立即学习“go语言免费学习笔记（深入）”；
- Cookie 必须设
HttpOnly（防 XSS 读取）、Secure（仅 HTTPS 传输）、SameSite（推荐Lax或Strict）：http.SetCookie(w, &http.Cookie{ Name: "session_id", Value: token, HttpOnly: true, Secure: true, SameSite: http.SameSiteLaxMode, }) - 若 Go 直接监听 TLS（
http.ListenAndServeTLS），务必禁用弱协议：通过http.Server.TLSConfig设置MinVersion: tls.VersionTLS12，并移除tls.TLS_RSA_WITH_*等已弃用密码套件 - 重定向时避免开放重定向漏洞：检查
r.URL.Query().Get("next")是否为绝对 URL 或站内路径，禁止以http://、https://、//开头的跳转目标
实际部署中，最易被忽略的是 Cookie 的 SameSite 属性缺失导致 CSRF 风险，以及开发环境未区分 Secure 标志导致登录态在 HTTP 下明文传输。这些不是“加个中间件就能解决”的问题，而是每个响应、每次 SetCookie 调用都需确认的细节。
