起初我虽然同源策略意味着从不同域加载的 JS 无法在页面上执行。但是在阅读了this、this 和this 之后，我变得一头雾水。声称是，如果您在脚本标签的src 属性中加载 JS，则加载的脚本与加载页面具有相同的来源，这意味着来自 CDN 或第三方（谷歌分析等）的所有内容现在都可以完全访问DOM 等。对我来说，这看起来像是一个可怕的安全漏洞。这意味着如果 CDN 或类似内容遭到破坏，攻击者可能会提供恶意 JS，例如，从多个站点窃取用户名/密码。那我理解对了吗？
【问题讨论】：
标签： javascript same-origin-policy
您确实理解正确。从第三方加载脚本会带来可怕的安全风险，并且在很多情况下，广告网络或分析提供商被用于在其他未受破坏的网站上传递恶意内容。
不，同源策略不是为了防止这种情况发生。它旨在保护提供给用户的机密数据不被任意其他域上的 XHR（和其他技术）访问。
【讨论】：
我已将我的评论作为答案，因此我可以引用参考以确保完整性
您正确理解 CORS/SOP，但不了解它的用途。
CORS 和 SOP 并非旨在防止 XSS 攻击 - 它们旨在允许主机保护访问其数据的人员。
请看以下内容，取自https://security.stackexchange.com/questions/108835/how-does-cors-prevent-xss
TL;DR：CORS 如何防止 XSS？它不是。不是故意的。
CORS 旨在允许资源主机（通过 HTTP 提供其数据的任何服务）限制哪些网站可以访问该数据。
示例：您正在托管一个显示流量数据的网站，并且您正在网站上使用 AJAX 请求。如果没有 SOP 和 CORS，任何其他网站都可以通过简单的 AJAXing 到您的端点来显示您的流量数据；任何人都可以轻松“窃取”您的数据，进而窃取您的用户和您的资金。
在某些情况下，数据共享（跨源资源共享）是有目的的，例如在您的网页上显示来自 Facebook API 的喜欢和内容时。由于上一段中解释的原因，简单地删除 SOP 来实现这一点是一个坏主意。于是就引入了 CORS。
CORS 与 XSS 无关，因为任何可以将恶意 JavaScript 片段放入网站的攻击者也可以设置发送正确 CORS 标头的服务器。 CORS 无法阻止恶意 JavaScript 将会话 ID 和永久登录 cookie 发送回攻击者。
【讨论】：
声称如果您在脚本标签的 src 属性中加载 JS，则加载的脚本与加载页面具有相同的来源，
是的。来源是由 HTML 文档的来源定义的，而不是其他任何东西。
这意味着来自 CDN 或第三方（Google anaytics 等）的所有内容现在都可以完全访问 DOM 等。
是的。这就是为什么您必须完全信任您允许在您的页面上执行的任何 JS 的来源。
对我来说，这看起来像是一个可怕的安全漏洞。这意味着如果 CDN 或类似内容遭到破坏，攻击者可能会提供恶意 JS，例如，从多个站点窃取用户名/密码。
这是一个风险。 It has happened in the past.
如果您选择使用 CDN，那么您必须相信他们在安全方面足够出色，不会发生这种情况。
至于同源策略的实际作用：See this answer。
【讨论】：
这绝对是您在使用 CDN 时要承担的风险 - 因此，浏览器现在开始实现 Subresource Integrity (SRI)，它允许您在脚本/链接标签上放置校验和 - Bootstrap 文档提供一个例子：
<link rel="stylesheet"
href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css"
integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u"
crossorigin="anonymous">
如果哈希与加载的实际文件不匹配，则资源被阻止。然而，这显然只能保护使用支持 SRI 的浏览器的用户。
【讨论】：