要只允许同源脚本执行来防护XSS攻击，最有效的技术手段是配置内容安全策略（CSP），通过设置script-src 'self'指令，严格限定脚本仅能从与页面相同的协议、域名和端口加载。这个策略直接阻断了外部恶意脚本的注入和执行路径，是构建前端安全防线的核心实践。

理解CSP在XSS防护中的核心作用

内容安全策略（CSP）是一个附加的安全层，它通过HTTP响应头或HTML的<meta>标签告知浏览器，哪些来源的资源是可信的、可以被加载或执行的。对于跨站脚本攻击（XSS），攻击者通常试图将恶意脚本注入到网页中，当其他用户访问时，这些脚本就会在其浏览器上下文中执行。CSP的script-src指令正是为此设计的。当你将其值设置为'self'时，就等于告诉浏览器：“只执行那些来自本网站自身源（同源）的脚本文件，其他任何地方的脚本都一律阻止。”这从根本上消除了通过注入<script>标签或内联事件处理器来执行外部恶意代码的可能性。

配置“只允许同源”的CSP策略

实现这一策略有两种主要方式。第一种是通过服务器端设置HTTP响应头，这是最推荐且最安全的方法。你需要在服务器的配置中添加类似以下的响应头：

Content-Security-Policy: script-src 'self';

这行指令非常简单，但威力巨大。它意味着所有JavaScript，无论是通过<script src="...">引入的外部文件，还是内联脚本，只要其来源不是与页面同源，都会被浏览器拦截。第二种方式是通过HTML的<meta>标签设置，适用于无法方便修改服务器配置的场景：

<meta http-equiv="Content-Security-Policy" content="script-src 'self'">

需要注意的是，<meta>标签的方式在某些情况下（如对于框架的指令）可能支持不完整，HTTP头方式是更权威和全面的选择。

处理内联脚本和eval类函数的挑战

仅仅设置script-src 'self'会带来一个直接问题：它会默认阻止所有内联脚本（包括直接写在HTML中的<script>块和HTML元素上的事件处理器如onclick）以及eval()、setTimeout(string)等动态代码执行函数。这对于大量使用内联脚本的旧项目来说是破坏性的。有几种解决方案：首先，最佳实践是重构代码，将所有的JavaScript移到外部的、同源的.js文件中。这不仅能满足CSP要求，也使代码更易于维护和缓存。其次，如果必须使用内联脚本，CSP提供了'unsafe-inline'指令，但强烈不建议使用，因为它会为XSS攻击打开后门。一个更安全的折衷方案是使用nonce或hash。例如，你可以为每个内联脚本生成一个一次性的加密随机数：

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
  // 你的内联脚本代码
</script>

同时在CSP头中允许带有该nonce的脚本：

Content-Security-Policy: script-src 'self' 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa';

这样，只有nonce值匹配的内联脚本才会被执行，攻击者无法猜测或伪造有效的nonce。

平衡安全性与第三方依赖的集成

现代Web应用几乎不可避免地会使用一些第三方资源，例如从CDN加载的JavaScript框架（如React、Vue）、统计分析代码或地图API。严格的'self'策略会阻止这些资源的加载，导致功能失效。这时，你需要精确地放宽策略。正确的做法不是简单地使用通配符*或'unsafe-eval'，而是将可信的第三方来源明确地加入白名单。例如，如果你需要使用来自"cdn.example.com"的Vue.js，你的CSP头应该这样配置：

Content-Security-Policy: script-src 'self' https://cdn.example.com;

这表示浏览器允许执行来自本网站源和"https://cdn.example.com"源的脚本。关键在于，你应该对每个需要引入的第三方资源进行审计，只添加那些绝对必要且来源可信的域名。同时，尽量使用这些第三方资源的具体版本URL或子资源完整性校验，以增加安全性。

报告与监控：让CSP策略持续优化

直接部署一个严格的CSP可能会因为拦截了未预料到的合法脚本而导致网站功能异常。为了避免这种情况，CSP提供了报告机制。你可以使用Content-Security-Policy-Report-Only头来先进行“试运行”。

Content-Security-Policy-Report-Only: script-src 'self'; report-uri /csp-violation-report-endpoint;

这个头不会真正阻止任何内容，但会将所有策略违规行为以JSON格式报告到你指定的端点。通过分析这些报告，你可以全面地了解哪些脚本被策略拦截了，从而判断它们是合法的需要加入白名单的资源，还是潜在的恶意攻击尝试。在监控一段时间、确认所有合法功能都正常且没有误报后，再将Report-Only头替换为强制的Content-Security-Policy头，完成策略的正式上线。

独到见解：将CSP视为纵深防御的起点而非终点

虽然“只允许同源脚本执行”的CSP配置是防御XSS的强力武器，但我们必须清醒地认识到它并非银弹。它属于一种“纵深防御”策略。首先，CSP主要缓解的是反射型和部分存储型XSS，对于完全基于DOM的XSS，如果恶意代码是通过合法的同源脚本文件中的漏洞执行的，CSP可能无能为力。其次，CSP的有效性高度依赖于“同源”这个概念的安全性。如果你的主站本身存在上传漏洞，导致攻击者能将恶意.js文件上传到你的服务器域名下，那么这些恶意文件就变成了“同源”资源，从而绕过CSP的防护。因此，CSP必须与服务器端的安全措施（如严格的输入验证、输出编码、使用安全的框架等）结合使用。真正的安全架构是将CSP作为最后一道坚固的防线，同时确保前端的代码质量和后端的逻辑安全无懈可击，共同构成一个立体的、多层次的防御体系。