模板注入漏洞本质是开发者将用户输入当作模板语法执行所致；需重点审查art-template中template.compile()传入动态字符串、{{= data}}或{{@data}}绑定用户输入、template.defaults非安全配置等高危调用。
模板注入漏洞不是前端框架本身的缺陷，而是开发者把用户输入当作模板代码执行导致的。只要用了 template.compile()、new Function()、eval() 或类似动态编译逻辑，并把用户可控内容传进去，就极可能中招。
怎么快速定位 art-template 的高危调用
art-template 默认开启 HTML 转义，但一旦用 template.compile() 动态构造模板字符串，就绕过了所有安全机制。重点盯住以下几类代码：
- 调用
template.compile(userInput)—— 无论 userInput 来自 URL、表单还是 localStorage，都危险 - 模板字符串里用了
{{= data}}或{{@data}}，且data是用户输入而非内部变量 -
template.defaults被显式修改过，比如cache: false或compileDebug: true，会增加调试信息泄露和重复编译风险
Vue 和 React 里哪些写法实际等价于模板注入
Vue 和 React 默认不支持服务端模板编译，但某些开发习惯会“手动造轮子”，结果引入等效漏洞：
- 在 Vue 中用
v-html渲染用户输入，且该输入来自后端未过滤字段（如评论富文本）——这不算模板注入，但效果类似，且更常见 - 用
new Function('return ' + userInput)()动态计算表达式，比如实现“公式引擎”或“条件规则”解析 - React 中滥用
dangerouslySetInnerHTML+ 服务端拼接的 HTML 字符串，尤其当字符串含onerror、javascript:等内容时
为什么 innerHTML = template(data) 不一定安全
即使你用的是预编译模板（如 template = template.compile('static.tpl')），只要最终赋值给 innerHTML 的是用户控制的 data，且 data 包含可被浏览器执行的结构（如 <img src="x" onerror="alert(1)">），就仍属 XSS 范畴，而非常规意义的模板注入。但排查思路一致：确认 data 是否完全可信。
- 检查
data来源：是数据库读取？API 返回？URL 参数？localStorage？每种来源都要单独评估信任等级 - 注意间接污染：比如
data.title看似安全，但若它来自用户编辑的 Markdown 解析结果，而解析器没过滤 HTML 标签，则仍危险 - 不要依赖前端校验：哪怕
title字段在提交前被 JS 过滤了<script></script>，后端返回时也可能被篡改或缓存污染
真正容易被忽略的点是：模板引擎的安全配置只在初始化时生效，后续对 template.compile() 的每次调用都独立承担风险；一次漏审，全盘失守。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
