XSS是JavaScript中最常被触发、最容易忽略且后果最直接的安全风险，防御核心是确保不可信数据不变成可执行代码，需按输出上下文（HTML/JS/URL）采用对应转义或净化方案。
为什么 innerHTML 是 XSS 的“快捷入口”？
因为 innerHTML 把字符串当 HTML 解析执行，而不是当纯文本显示。哪怕只是渲染一条用户评论、URL 参数里的 name、或者搜索框回显内容，只要没处理，<script>fetch('/api/steal?c='+document.cookie)</script> 就能跑起来。
- ❌ 错误写法：
element.innerHTML = '<div>' + userInput + '</div>'
- ✅ 正确写法（纯文本场景）：
element.textContent = userInput
—— 浏览器自动转义，连<都显示为文字 - ✅ 正确写法（必须渲染 HTML 的场景）：用
DOMPurify净化，不是自己写正则过滤：import DOMPurify from 'dompurify';<br>element.innerHTML = DOMPurify.sanitize(dirtyHTML);
不同上下文要用不同的转义方式
“转义”不是万能的，关键在匹配输出位置。把 URL 参数直接拼进 location.href，HTML 实体转义毫无用处；同理，在 JS 字符串里插用户数据，只做 HTML 转义也挡不住 ");alert(1)// 这类攻击。
- 插入 HTML 内容（如
innerHTML）→ 用 HTML 实体转义：&→&，<→ - 插入 JS 字符串（如
var msg = "xxx"）→ 用 JavaScript 字符串转义：\、"、'、`都要加反斜杠或 Unicode 编码 - 插入 URL 查询参数（如
location.search = '?q=' + userInput）→ 必须用encodeURIComponent()，不能用encodeURI()（后者不编码/ ? : @ & = + $ , #）
CSP 不是可选配置，而是最后一道保险
即使代码写得再小心，一个未更新的第三方库、一次 CDN 资源劫持，都可能绕过所有前端逻辑。这时候 Content-Security-Policy 就起作用了：它由服务端通过 HTTP 响应头下发，告诉浏览器“只允许从哪些来源加载脚本”。
- 基础策略示例（禁止内联脚本和 eval）：
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'; base-uri 'self';
- 关键点：
script-src 'self'会阻止所有<script>标签和内联事件（如onclick），但不会影响textContent或setAttribute - ⚠️ 注意：CSP 无法修复已存在的 DOM 型 XSS（比如
document.write(location.hash)），它只是让恶意脚本“加载不了”或“执行不了”
富文本场景最容易翻车，别信“白名单过滤”
很多团队以为只要允许 <p><strong><a> 就安全了，结果攻击者用 <a href="javascript:alert(1)">、<img onerror="alert(1)" src=x> 或绕过正则的嵌套注释直接触发执行。
立即学习“Java免费学习笔记（深入）”；
- ❌ 自己写正则清洗 HTML → 极易被绕过，且维护成本高
- ❌ 用
innerHTML + 白名单字符串替换→ 属性顺序、大小写、编码变体都能绕过 - ✅ 唯一推荐方案：用
DOMPurify（经 OWASP 认证）并开启强制属性清理：DOMPurify.sanitize(dirty, { <br> ALLOWED_TAGS: ['p', 'strong', 'a'],<br> ALLOWED_ATTR: ['href'],<br> FORBID_CONTENTS: ['script', 'object', 'embed']<br>});
