XSS防护需结合输入处理、输出编码与上下文感知，通过多层防御体系阻断攻击。首先对用户输入按目标上下文进行HTML或JavaScript编码，插入HTML时优先使用textContent，动态渲染则转义特殊字符；在脚本中嵌入数据时采用JSON.stringify或专用转义函数防止代码注入。部署CSP作为最后一道防线，限制script-src为'self'及可信CDN，禁用'unsafe-inline'与'unsafe-eval'，并结合nonce或hash机制授权合法脚本。针对富文本输入，使用DOMPurify等库实施白名单过滤，保留p、strong、a等安全标签，剔除script、iframe及onerror事件，同时约束a标签仅允许http/https/mailto协议。前端避免将URL参数直接写入页面，禁用document.write和eval，改用addEventListener绑定事件。最终需将XSS防范融入开发全流程，持续更新依赖、审计代码并启用安全响应头以维持防护有效性。
面对XSS（跨站脚本攻击），JavaScript应用必须从输入处理、输出编码和上下文感知三方面构建防御体系。单纯依赖某一种手段无法彻底解决问题，关键在于多层防护与开发习惯的结合。
正确进行HTML与JavaScript内容编码
用户输入在插入到页面前，必须根据目标上下文进行相应编码：
- 插入HTML内容时，使用textContent而非innerHTML，避免标签解析
- 动态生成HTML需对<、>、&、"、'等字符进行实体转义
- 在JavaScript字符串中嵌入数据时（如<script>var data = "...";</script>），应使用JSON序列化或专用转义函数处理引号和换行
使用内容安全策略（CSP）限制执行源
CSP是防止XSS的最后一道防线，通过HTTP头控制资源加载和脚本执行：
- 设置Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com，禁止内联脚本和eval
- 避免使用'unsafe-inline'和'unsafe-eval'，它们会削弱CSP效果
- 配合nonce或hash机制允许特定脚本执行，提升灵活性与安全性平衡
对富文本采用白名单过滤
当业务需要支持HTML输入（如编辑器内容），不能简单放行，而应：
立即学习“Java免费学习笔记（深入）”；
- 使用成熟库如DOMPurify对HTML进行净化，仅保留安全标签和属性
- 配置标签白名单（如p, strong, em, a），移除script, iframe, onerror等危险元素
- 对a标签的href属性限制协议（仅允许http/https/mailto）
避免危险的客户端操作
前端代码本身也可能引入XSS漏洞，需规避以下行为：
- 不要将URL参数直接写入页面，尤其是location.hash或search中的内容
- 禁用document.write和eval，它们容易执行恶意代码
- 使用addEventListener代替onclick=""内联事件绑定
基本上就这些。XSS防护不是一次配置就能高枕无忧的事，需要贯穿开发、测试和部署全过程。保持更新依赖库、定期审计代码、开启浏览器安全头，才能有效降低风险。
