HTML5本身不防注入，关键在于前端如何安全使用innerHTML、eval、URLSearchParams等；必须对用户输入转义或用textContent，禁用内联脚本与javascript:协议，CSP仅为兜底而非主力。
HTML5 本身不提供防注入能力，所谓“HTML5 防注入”实际是前端配合后端，在数据渲染、用户输入、脚本执行等环节堵住常见攻击入口。关键不在 HTML5 新标签，而在你如何用 innerHTML、document.write、eval、URLSearchParams 和模板字符串这些地方。
别用 innerHTML 渲染不可信内容
这是 XSS 最常见的突破口。哪怕只渲染一个用户昵称，如果直接拼接进 innerHTML，就可能执行恶意脚本。
正确做法是用 textContent 替代，或手动转义后再插入：
const unsafe = 'John';
const el = document.getElementById('name');
el.textContent = unsafe; // 安全：显示为纯文本
// 或需保留简单格式时，仅对特定字符转义：
function escapeHtml(str) {
return str
.replace(/&/g, '&')
.replace(//g, 'youjiankuohaophpcn')
.replace(/"/g, '"')
.replace(/'/g, ''');
}
el.innerHTML = escapeHtml(unsafe); // 仅在必须用 innerHTML 时才这么做
- 永远不要把
location.search、localStorage、fetch返回的 JSON 字段，未经校验/转义就塞进innerHTML -
insertAdjacentHTML同样危险，规则一致 - 框架如 React/Vue 默认做了转义，但显式使用
v-html或dangerouslySetInnerHTML就绕过了防护
谨慎处理 URL 和查询参数
通过 URLSearchParams 或正则解析 URL 参数后，直接用于重定向、fetch 地址或 iframe src，可能触发开放重定向或接口越权。
立即学习“前端免费学习笔记（深入）”；
例如：https://site.com/?next=javascript:alert(1) —— 如果代码写成 window.location = new URLSearchParams(location.search).get('next')，就中招了。
- 对跳转目标做白名单校验：
if (url.startsWith('/'))或匹配预设域名 - 避免用
eval、setTimeout(string)、setInterval(string)执行动态字符串 - 用
new URL(url)解析后检查.protocol，拒绝javascript:、data:、vbscript:
禁用内联事件和 javascript: 协议
HTML5 允许更灵活的语义化标签，但也让开发者更容易写出带风险的写法，比如：
链接
这类写法无法被 CSP 有效拦截（尤其服务端模板未转义时），且绕过现代框架的响应式绑定机制。
- 一律改用
addEventListener绑定事件 - 所有
href值确保以/、https://、#开头，禁止拼接用户输入 - 服务端渲染时，对输出到 HTML 属性中的变量，必须做上下文敏感转义（HTML 属性值、JS 字符串、URL 等场景转义规则不同）
CSP 是最后一道防线，但不能替代编码规范
Content Security Policy（CSP）能限制 eval、内联脚本、外部域资源加载，但它只是兜底策略，不是防注入的主力手段。
典型错误配置：Content-Security-Policy: script-src 'unsafe-inline' —— 这等于关掉了最有效的 XSS 阻断项。
- 优先使用非内联方式：把 JS 提取到独立文件，用
script-src 'self' - 若必须用
nonce，每次响应生成唯一值，并同步写入和响应头 - CSP 对 DOM-based XSS（如
location.hash触发的）防护有限，仍需前端代码自查
真正难防的是那些“看起来无害”的组合：比如用户输入进了 JSON.stringify() 再插进 script 标签，或者用 atob() 解码后 eval —— 这些不会被 CSP 拦截，却可能执行任意代码。防注入不是加个头或换种写法就能一劳永逸，而是每个数据流动节点都要问一句：这串字节，我敢让它当代码跑吗？
