判断模板是否拼接用户输入的关键是看用户输入是否被当作模板语法执行，而非仅作数据渲染；重点审查new Template()、StringReader、动态拼接字符串等危险调用，以及include/import路径是否含用户可控参数。
怎么判断模板是否在拼接用户输入
模板注入漏洞的起点，永远是「用户输入有没有被当成模板语法执行」。关键不是看用了什么引擎，而是看数据流向。
常见错误现象：Template(templateStr + userInput)、new Template('name', new StringReader(userInput))、res.render('index', { html: userInput }) 且模板里写了 ${html} 但没转义。
- FreeMarker 中查
new Template(…)构造器调用，尤其参数含StringReader或拼接字符串 - art-template 查
template.compile()是否传入动态生成的字符串，而非预存文件路径 - 所有引擎都重点盯住「模板内容来源」：是磁盘文件？还是运行时拼接？后者几乎必然危险
为什么默认转义不能代替输入隔离
默认 HTML 转义（如 art-template 的 {{data}}）只防 XSS，不防模板注入。它把 <script></script> 变成文字，但挡不住 ${userInput?eval} 这类语法执行。
使用场景差异明显：前端渲染用户评论，用 {{comment}} 安全；后端动态生成邮件模板，若把用户昵称直接拼进 FTL 字符串，${nickname} 就会变成执行入口。
立即学习“前端免费学习笔记（深入）”；
- FreeMarker 的
?eval、?interpret、#{...}表达式解析函数必须禁止在用户可控上下文中出现 - art-template 的
{{@data}}（绕过转义）和{{= data}}（JS 表达式）同样危险，除非 data 是完全可信的内部变量 - 任何引擎里，
include/import指令如果路径含用户输入，就是目录遍历+任意文件读取的温床
代码审查时该盯哪几行配置和调用
真正起作用的防护不在业务逻辑层，而在引擎初始化和模板加载环节。漏掉这些，后面再严谨也白搭。
FreeMarker 示例：必须检查 Configuration 实例是否禁用了危险指令：
cfg.setClassicCompatible(false); cfg.setTemplateExceptionHandler(TemplateExceptionHandler.RETHROW_HANDLER); cfg.setNewBuiltinClassResolver(TemplateClassResolver.SAFER_RESOLVER); // 关键
art-template 示例：审查 template.defaults 是否关闭了高危选项：
template.defaults.minimize = true; // 压缩 HTML，但不解决注入 template.defaults.compileDebug = false; // 关闭调试信息，避免泄露路径 template.defaults.cache = true; // 启用缓存，防止重复编译不可信内容
- FreeMarker 必须确认
setNewBuiltinClassResolver设为SAFER_RESOLVER或自定义白名单，否则?api可调用任意类 - 所有引擎的
ObjectWrapper（或等效配置）不能暴露getClass()、newInstance()等反射方法 - 检查模板加载器：是否限制了
file://、jar://协议？是否校验文件扩展名和路径前缀？
为什么自动化扫描总漏掉真实漏洞
静态扫描工具擅长找 eval、innerHTML 这类显眼危险函数，但对模板注入无能为力——因为触发点藏在数据流里，而不是某一行代码上。
一个典型漏报场景：用户输入先经 JSON.stringify() 处理，再塞进模板字符串。工具看到的是字符串拼接，不会意识到这个 JSON 里可能含 "${...}" 语法。
- 人工审查必须跟踪「输入 → 存储/传输 → 模板构造 → 渲染」全链路，不能只看单个函数调用
- 重点关注中间态：比如用户输入存进 DB 后又被读出拼模板；或前端加密后传给后端解密再拼接
- 测试用例要覆盖边界字符：
${1+1}、#{'freemarker.template.utility.Execute'?new()}、{{=alert(1)}}，观察是否执行
最常被忽略的点：模板引擎的「安全模式」往往只在新实例中生效，老的 Configuration 全局单例可能还开着 UNSAFE_RESOLVER，而代码里又没显式重置——这种配置漂移，比代码逻辑更难发现。
