flawopen.com/XSS/CSP vs. escape
CSP 与输出转义：XSS 防护需要两者吗？
上下文相关的输出编码会将不可信值作为数据放入页面，而不是作为可执行标记。Content Security Policy（CSP）是第二道防线：它像检查脚本执行权限和连接目标的门卫，在编码遗漏时可以阻止部分注入行为。它不会修复遗漏本身；宽松的策略也可能无法阻止脚本。
两种防护各自的作用
在数据进入输出上下文时进行编码。HTML 文本、带引号的属性、JavaScript、CSS 和 URL 组件有不同的解析规则；应根据准确上下文选择编码器。优先使用框架模板和安全的 DOM sink，避免将不可信值放入 inline script 或事件处理属性等可执行上下文。这是预防 XSS 的主要措施。
强制执行的 Content-Security-Policy 可限制 inline script、脚本来源和 connect-src 等连接目标。如果编码遗漏，合理设计的策略可能阻止某个注入脚本或连接。效果取决于策略和浏览器；CSP 不保证阻止所有 payload、数据泄露或 script gadget，注入漏洞依然存在。
为什么 CSP 不能替代输出编码
宽松或配置错误的策略可能让注入继续执行。例如，允许 'unsafe-inline' 会削弱对 inline script 的保护；宽泛的主机 allowlist 也可能放行可提供脚本的 endpoint。CSP 指令用途不同：限制 script-src 后，仍可能需要有意配置 connect-src 来限制网络目的地。Content-Security-Policy-Report-Only 只报告违规，不会阻止它们。用输出编码修复问题，用 CSP 纵深防御。
常见问题
盘点所需脚本，测试基于 nonce 或 hash 且不含 'unsafe-inline'、'unsafe-eval' 的策略。先用 Content-Security-Policy-Report-Only 发现兼容问题；它不会强制执行。检查报告、调整必要依赖，然后部署强制执行的 Content-Security-Policy。整个过程中都要保留上下文编码。