应手动清除或覆盖Server头、使用html/template自动转义防XSS、SQL查询用参数化、设置X-Content-Type-Options/nosniff等安全头、Cookie设HttpOnly/Secure/SameSite属性。
默认情况下,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 没有“魔法引号”或自动转义机制,所有输出和拼接都需开发者主动防护。模板渲染和数据库查询是两个高危场景。
html/template(而非 text/template),它会自动对 .Name 等字段做上下文敏感转义;若需插入可信 HTML,请显式调用 template.HTML(...)
db.Query 或 db.Exec 的参数化方式:db.Query("SELECT * FROM users WHERE id = $1 AND status = $2", userID, "active"),$1/$2 是 PostgreSQL 占位符;MySQL 用 ?,
/user/:id)需校验格式:用 strconv.ParseInt(id, 10, 64) 替代直接转 int,失败即返回 http.StatusBadRequest
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' 或改用事件委托 + 外链很多团队用反向代理(如 Nginx)终止 TLS,导致 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,
})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 调用都需确认的细节。