Iris的API接口天然免疫XSS，因ctx.JSON()等不解析HTML；真正风险在于ctx.HTML()或模板渲染时未转义用户数据，需手动html.EscapeString或依赖html/template默认转义，同时前端避免innerHTML、服务端配CSP及HttpOnly Cookie。
API接口根本不会触发XSS，但Iris返回HTML时才需防范
直接说结论：Iris作为Go Web框架，其ctx.JSON()、ctx.XML()等API响应方式本身不解析HTML，也不执行JavaScript，因此纯JSON API接口**天然免疫XSS**。真正需要防XSS的场景，是Iris用ctx.HTML()或ctx.View()渲染服务端模板并插入用户数据时。
用ctx.HTML()返回HTML页面时，必须手动转义用户数据
Iris不自动转义模板中的变量，所有{{.Name}}这类插值都原样输出——如果Name来自用户输入（如URL参数、表单），就极可能被注入<script></script>标签。
- 错误写法：
ctx.HTML(200, "<div>Hello {{.Name}}</div>", iris.Map{"Name": r.URL.Query().Get("name")})→ 若name=<script>alert(1)</script>，浏览器直接执行脚本 - 正确做法：始终对用户数据调用
html.EscapeString()后再插入HTML - 示例修复：
import "html" name := html.EscapeString(r.URL.Query().Get("name")) ctx.HTML(200, "<div>Hello "+name+"</div>", nil) - 若用
iris.HTML(...)注册模板引擎（如html/template），可利用其内置转义：{{.Name}}默认已转义，但{{.Name | safeHTML}}会跳过转义——务必避免对不可信数据使用safeHTML
返回JSON时也要警惕“伪XSS”：前端JS拼接导致的DOM型XSS
虽然ctx.JSON()本身安全，但如果前端拿到JSON后用innerHTML = data.name直接插入DOM，就等于把XSS风险移交给了客户端。
- 典型错误：
// Iris后端 ctx.JSON(iris.Map{"name": r.URL.Query().Get("name")}) // 前端JavaScript document.getElementById("out").innerHTML = response.name; // 危险！ - 安全替代方案：
- 用
textContent代替innerHTML（仅显示纯文本） - 若必须渲染HTML，用
DOMPurify.sanitize()清洗后再插入 - 服务端提前过滤敏感字符（如
、<code>>、"），而非依赖前端
- 用
Content-Security-Policy头是最后一道防线，Iris中必须显式设置
即使所有输出都转义了，CSP能阻止未预期的脚本执行，比如通过eval()、内联onerror事件或javascript: URL触发的XSS。
- Iris中设置方式：
app.Use(func(ctx iris.Context) { ctx.Header("Content-Security-Policy", "default-src 'self'; script-src 'self' 'unsafe-inline';") ctx.Next() }) - 关键点：
-
script-src 'self'禁止加载外部脚本，大幅降低攻击面 - 避免
'unsafe-inline'和'unsafe-eval'，改用nonce或hash白名单机制 - 对Cookie启用
HttpOnly（虽不属Iris职责，但需在ctx.SetCookie()时传iris.CookieHTTPOnly(true)）
-
最容易被忽略的是：DOM型XSS完全绕过服务端转义，它只依赖前端代码漏洞；而CSP配置一旦漏掉script-src或误配'unsafe-inline'，就等于没设。防XSS不是加一个函数的事，是输入校验、输出转义、CSP、HttpOnly Cookie四层缺一不可。
