JavaScript安全漏洞与XSS防御技巧

今日不肯埋头，明日何以抬头！每日一句努力自己的话哈哈~哈喽，今天我将给大家带来一篇《JavaScript安全风险及XSS防御方法》，主要内容是讲解等等，感兴趣的朋友可以收藏或者有更好的建议在评论提出，我都会认真看的！大家一起进步，一起学习！

XSS是JavaScript中最常被触发、最容易忽略且后果最直接的安全风险，防御核心是确保不可信数据不变成可执行代码，需按输出上下文（HTML/JS/URL）采用对应转义或净化方案。

为什么 innerHTML 是 XSS 的“快捷入口”？

因为 innerHTML 把字符串当 HTML 解析执行，而不是当纯文本显示。哪怕只是渲染一条用户评论、URL 参数里的 name、或者搜索框回显内容，只要没处理， 就能跑起来。

• ❌ 错误写法：

  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' 会阻止所有