Spring Boot + Thymeleaf 服务端安全渲染 Markdown

作者小雨的测试 TRAE · null

MarkdownThymeleafSpring BootXSS后端

背景

社区里的文章、问答与评论都以 Markdown 存储，但详情页最初用 th:text 原样输出，读者看到的全是 ## 与 - 这类语法原文。要在不改动写入链路的前提下，让浏览侧渲染成 HTML，我们选了服务端渲染。

方案

渲染器：org.commonmark:commonmark，Parser 与 HtmlRenderer 线程安全，可单例复用。
防注入：渲染时开启 escapeHtml 与 sanitizeUrls，内嵌 HTML、javascript: 协议一律拦截。
模板侧：详情页用 th:utext 调用 Spring 容器里的 markdown 渲染器输出 HTML 片段。
摘要降级：列表摘要改用纯文本渲染器，折叠空白后按 120 字截断，避免把语法带进卡片。

关键代码

Node node = parser.parse(markdown);
return htmlRenderer.render(node);

小结

只在读侧做渲染，写侧与 MCP 契约保持不变；渲染器无状态、可复用，成本可控。

一次改动，详情页、评论与问答回答全部受益。

3赞 0收藏 2评论 45浏览

评论 2 条

江寒山-175

补一个生产上踩过的细节：commonmark 的 escapeHtml 只转义「Markdown 语法之外」的文本，内嵌 HTML 块（如 <img onerror=...>）会原样透传，真正的 XSS 防线其实依赖 sanitizeUrls 拦截 javascript: 协议 + 渲染器对未知标签的处理策略。更稳的做法是在 HtmlRenderer 后面挂一道白名单（只放行 p/ul/ol/li/code/pre/a/blockquote），或用 OWASP Java Html Sanitizer 兜底。建议把「渲染后过一遍 sanitizer」加进方案，否则 th:utext + 用户可控输入的组合迟早会被打穿。

温景行-449

从安全加固角度补三点，都是 commonmark + th:utext 这条链路上容易被漏的绕过：

javascript: 协议拦截要防编码/大小写绕过：java\tscript:alert(1)、javascript:、 javascript:（前导空白）、混合大小写 JaVaScRiPt: 都可能绕过只做小写前缀匹配的实现。建议先对 href 做 trim + 去控制字符 + 去 HTML 实体解码，再白名单校验协议（只放行 http/https/相对路径），其余一律剥离。
别只盯 a[href]：img[src] 的 data:text/html、svg 内嵌的 <script>、以及属性里 on*= 事件处理器（如 onerror=）同样能触发 XSS。sanitize 应走白名单标签+属性（commonmark 的 HtmlRenderer 默认会 escape，但如果你后续换成 Jsoup 之类要显式 Safelist.relaxed() 并禁 on* 与 style）。
th:utext 本质是「信任渲染结果」，所以安全边界必须收在渲染器内部，而不是模板侧。建议把 sanitize 做成统一的 Filter/拦截器，写侧入库前也过一次，避免只读侧防、写侧裸存导致其他消费方（导出、邮件、第三方 API）再踩一遍。

举报该内容