buffalo 框架不内置 xss 防护，需手动控制模板渲染与数据流向：禁用 html.unsafe、过滤富文本、避免 innerhtml 直接插入服务端数据。
Buffalo 框架本身不内置 XSS 防护中间件，也不自动对模板输出做 HTML 转义（不像 Rails 的 erb 默认转义或 Django 的模板系统）。这意味着：XSS 风险完全取决于你如何渲染用户数据——用错函数、绕过转义、拼接 HTML，就直接中招。
关键判断：在 Buffalo 中防 XSS，核心不是“开启某个开关”，而是「控制模板渲染方式 + 约束数据流向」。后端无法替你兜底，必须从 render 和 html 模板函数两个层面主动设防。
模板里用 html.Unsafe 就等于开后门
Buffalo 默认使用 html/template，它会自动转义 .Name 这类变量插值（如输出 <script></script> 变成文字）。但一旦你显式调用 html.Unsafe 或 template.HTML 包装数据，就跳过了所有转义逻辑。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 常见错误：从数据库读取富文本（如用户评论），直接
{{ .Content | html.Unsafe }}渲染 - 真实风险：如果内容含
<img src="x" onerror="alert(1)">，浏览器会执行 - 正确做法：富文本必须走白名单过滤（如
bluemonday库），再转为template.HTML；普通字段一律不用html.Unsafe
buffalo.New() 时禁用自动 HTML 解析
Buffalo 默认允许在 Action 中返回 html 字符串并被当作未转义内容渲染（通过 c.HTML）。这不是 bug，是设计选择——但容易误用。
- 危险写法：
c.HTML(200, "<script>alert('xss')</script>")→ 直接输出原始 HTML - 安全替代：
c.Render(200, r.JSON(...))或c.Render(200, r.String(...))，强制走模板层转义 - 更彻底的约束：在
app.go初始化时，避免注册自定义 HTML 渲染器；若必须返回 HTML，先用bluemonday.Policy过滤字符串
前端 JS 读取服务端数据时别碰 innerHTML
Buffalo 的 data 属性（如 data-user='{{.User.Name}}'）在模板中会被自动转义，但前端 JS 若用 element.innerHTML = data，就重新打开了 DOM 型 XSS 通道。
- 典型场景：AJAX 返回 JSON，前端用
document.getElementById("name").innerHTML = res.name - 问题根源：服务端转义只管模板渲染，不管 JS 运行时行为
- 解法：改用
textContent渲染纯文本；若需 HTML，必须用DOMPurify.sanitize()处理后再赋值给innerHTML - 额外提醒：避免在
location.hash或URLSearchParams中解析并插入 DOM，这是 DOM 型 XSS 高发区
真正难防的从来不是反射型 XSS，而是你亲手把 html.Unsafe 当作“功能”加进模板、把未过滤的富文本当“内容”直接塞进 innerHTML——这两处没约束，其他所有配置都形同虚设。
