echo框架需通过secure中间件显式配置x-content-type-options、x-frame-options、content-security-policy三大安全头，默认不启用；须用gitlab.com/unrolled/secure路径导入v1.0.4版本，正确设置options并集成到路由链，https下启用hsts且开发环境跳过，最后用curl或浏览器验证响应头。
在Echo框架中为Web服务添加X-Content-Type-Options、X-Frame-Options、Content-Security-Policy等关键安全响应头，必须通过secure中间件显式配置，因为Echo.New()启动的服务默认不发送任何安全头——浏览器将按宽松策略解析响应，导致MIME混淆、点击劫持、内联脚本执行等风险直接暴露。
安装并初始化secure中间件
执行go get -u github.com/unrolled/secure命令安装最新版secure包。注意该包已归档，但v1.0.4仍是当前生产环境兼容性最稳定的版本，新项目请避免使用v2+分支。
在main.go中导入"gitlab.com/unrolled/secure"（非github路径，官方已迁移）并声明中间件变量：sec := secure.New(secure.Options{})。
这一步漏掉导入路径修正会导致编译失败，【gitlab.com/unrolled/secure】是唯一可用地址。
配置三大核心安全头
调用sec.Handler时传入完整Options结构体，必须显式启用以下三项：
• XContentTypes: true —— 输出X-Content-Type-Options: nosniff头，强制浏览器禁止MIME类型嗅探；
• FrameDeny: true —— 输出X-Frame-Options: DENY，彻底阻断iframe嵌套，防点击劫持；
• ContentSecurityPolicy: "default-src 'self'" —— 设置最小权限CSP策略，禁止加载外部脚本、样式、图片等资源。
这三项缺一不可。若只设前两项而忽略CSP，攻击者仍可通过data:或javascript:协议注入执行任意代码。
处理HTTPS与本地开发的差异
第一步：判断当前请求是否走TLS。用r.TLS != nil检查，不能依赖req.URL.Scheme字符串匹配，因为反向代理后Scheme可能未被更新。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
第二步：仅当r.TLS != nil时，才启用HSTS头。设置stsMaxAge: 31536000（一年），并强制includeSubdomains和preload标志。
第三步：开发环境（localhost或127.0.0.1）跳过HSTS写入。直接return不调用next.ServeHTTP会导致请求中断，必须保留next.ServeHTTP(w, r)调用链。
Strict-Transport-Security头在HTTP明文连接下发送会被浏览器直接丢弃，且可能触发开发者工具警告，【本地调试时务必绕过该头输出】。
集成到Echo路由链
方法一：全局注册——e.Use(sec.Handler)放在所有路由注册之前，确保每个HTTP响应都经过加固。
方法二：分组控制——对/public/*等静态资源路径禁用secure中间件，避免CSP干扰第三方CDN字体加载；对/api/*路径启用全量防护。
方法三：条件启用——在JWT校验中间件之后插入secure.Handler，防止未认证用户看到原始响应头暴露技术栈信息。
不要把secure.Handler放在Logger中间件之后——日志会记录原始未加固响应，失去审计意义。
验证响应头是否生效
启动服务后，用curl -I http://localhost:1323/发起请求，检查返回头中是否包含X-Content-Type-Options、X-Frame-Options、Content-Security-Policy三项。
若缺少X-Frame-Options，说明FrameDeny设为false或拼写错误；若Content-Security-Policy值为空字符串，说明Options结构体未正确传入该字段。
浏览器F12 → Network → Headers → Response Headers，逐项核对大小写和冒号后空格——Content-Security-Policy不能写成Content-Security-policy，否则Chrome会忽略该头。
