SVG内联使用极易引发XSS，因其支持脚本和事件处理器；防御须禁用未净化的SVG插入，优先用加载，必要时用DOMPurify等白名单库净化。

SVG在HTML5中是功能强大但风险较高的内联图形格式，尤其当动态插入或解析用户可控内容时，极易成为XSS攻击的入口。关键在于：SVG本身支持脚本执行（如<script></script>、事件处理器onload、onclick等），且嵌入HTML的方式（如<img alt="HTML5中SVG安全性分析及针对XSS攻击的防御" >、CSS background-image、<object></object>、<iframe></iframe>、内联<svg></svg>）会显著影响攻击面和防御策略。

内联SVG是最危险的使用方式

直接将SVG代码拼接到HTML中（例如通过innerHTML、document.write()或服务端模板渲染），等同于允许执行任意XML+HTML+JS混合内容。以下结构均可触发XSS：

• <svg onload="alert(1)"></svg>
• <svg><script>alert(1)</script></svg>
• <svg><g onclick="alert(1)">click me</g></svg>
• 利用CDATA绕过简单标签过滤：<svg><script><![CDATA[alert(1)]]></script></svg>

防御核心：禁止直接插入未清洗的SVG字符串；若必须内联，应使用专用SVG白名单库（如DOMPurify配置{USE_PROFILES: {svg: true}}）进行严格净化，而非正则替换。

外部SVG文件加载也有执行风险

看似安全的<img src="chart.svg" alt="HTML5中SVG安全性分析及针对XSS攻击的防御" >不会执行脚本，但以下方式会：

立即学习“前端免费学习笔记（深入）”；

• <object data="chart.svg" type="image/svg+xml"></object> —— 支持脚本与事件
• <iframe src="chart.svg"></iframe> —— 完整上下文，可访问父页面（若同源）
• <embed src="chart.svg" type="image/svg+xml"></embed> —— 行为类似<object></object>，已废弃但仍被支持

建议：优先用<img alt="HTML5中SVG安全性分析及针对XSS攻击的防御" >加载SVG（完全隔离脚本）；确需交互能力时，改用Canvas绘图或前端SVG库（如D3、Snap.svg）动态生成，避免加载不可信SVG文件。

服务端处理SVG需双重校验

用户上传SVG文件？不能只检查文件扩展名或Content-Type。攻击者常伪造.svg后缀，实际内容含恶意脚本。必须：

• 解析XML结构，拒绝含<script></script>、<foreignobject></foreignobject>、on\w+=属性、xlink:href指向javascript:等内容的文档
• 剥离所有xmlns:xlink命名空间（除非明确需要）——xlink常被用于<use xlink:href="javascript:alert()"></use>类攻击
• 限制DOCTYPE声明（禁止外部实体引用，防XXE）
• 转换为静态PNG/JPEG再返回（牺牲矢量特性，换取绝对安全）

CSS与HTML属性中的SVG也需警惕

以下写法可能触发非预期执行：

• CSS中background-image: url("data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" onload="alert(1)"></svg>");
• HTML属性值中拼接SVG（如title、data-* ）被JS二次解析为DOM时触发

原则：任何将用户输入拼入SVG字符串（无论base64、URL编码还是明文）的场景，都必须先做上下文感知的转义或拒绝。推荐使用encodeURIComponent()处理动态参数，而非直接注入到SVG模板中。

不复杂但容易忽略：SVG XSS不是边缘案例，而是现代Web应用中高频真实漏洞。防御不在“是否用SVG”，而在“如何控制它的执行边界”。