SOP（相同来源政策）的真正含义是什么？
我知道这意味着来自一个起源的Javascript代码不能指责来自另一个起源的resources。但是“资源”一词到底是什么意思？例如：
但是，当您使用JSON填充时，在完成填充脚本标签的加载之后，第3方脚本将调用您指定的回调-来自一个站点的Javascript代码正在从另一个站点调用Javascript代码的方法。这是否违反SOP？
JSONP通过将脚本标签动态添加到DOM并使用远程Web服务的JSON数据作为参数来调用预定义函数来解决“相同起源策略”。标签不受相同的来源政策约束，因此可以请求跨域内容。
[就像您可以在不违反SOP的情况下在网站上使用Google的jQuery版本一样，您可以“包括”一个脚本标签，该标签在从Web服务接收的数据上调用预定义的函数。
Same Origin Policy主要旨在防止其他域的脚本在已加载域的上下文中执行AJAX（XMLHTTP）请求，并且还限制其他域的站点访问站点资源，例如Cookie，本地存储等。更像是为安全措施制定的标准规范，每个浏览器都有遵循规范的实现方法。
通过说“防止其他域执行AJAX（XMLHTTP）请求的脚本”，我的意思是不属于同一域的跨域请求。
例如，domain.com和test.domain.com属于同一个域，而测试属于子域，而test.domain2.com属于完全不同的域。
现在让我们考虑它的安全隐患：-
1。假设我们的网站site1.com具有API调用来更新密码。当用户输入所需的数据时，将对后端进行HTTP调用，并使用cookie中包含的会话数据来验证用户的真实性。
2]现在这样说，如果攻击者创建了一个名为site2的站点，并且具有Javascript代码以对site1的更改密码端点进行HTTP调用。根据浏览器的默认行为，它将站点1拥有的所有cookie数据附加到请求，从而使HTTP调用成功，从而使攻击者能够成功。
3）为了减轻浏览器实施的SOP的影响，SOP指示浏览器的javascript引擎禁止任何跨域请求，例如从site2到site1的请求，除非得到指示允许这样做。
4）现在，在这个具有微服务架构和多个子域的不断发展的现代世界中，这将是非常有问题的。为了解决这个问题，如果API响应这样说明标头，则浏览器支持跨域请求，例如标头，如Access-Control-Allow-Origin，Access-Control-Allow-Methods，Access-Control-Allow-Credentials等。
5）要提出从site2到site1的ajax请求时，浏览器会检查API响应标头，并允许该请求（如果响应中存在以下任何值）：Access-Control-Allow-Origin：*或Access-Control-Allow-Origin：site2.com或Access-Control-Allow-Origin：*。site2.com（通配符输入）
6）话虽如此，这里仍然存在很大漏洞，即使sop策略阻止了该请求，这实际上也意味着浏览器阻止了site2访问以读取响应数据，这意味着该请求已向服务器发出。此方案仅适用于在不触发飞行前选项调用的特定条件下的一些请求。当进行选项调用时，浏览器将不允许基于选项调用中的标头响应通过请求。
7）现在第二部分是访问控制允许凭据。在服务器对选项调用的响应中，如果服务器将标头设置为true，则所有机密会话数据（如授权标头）均将安全cookie添加到从site2到site1的跨域请求中。]
注：-仅当Access-Control-Allow-Origin非常特定于域时才添加此标头，这意味着它不适用于标头中的*值。如果Access-Control-Allow-Origin标头为*，则如果Access-Control-Allow-Credentials设置为true，则浏览器SOP策略将启动并阻止其允许安全数据。
SOP原始策略不处理图像源，而包括外部脚本。为了能够控制这些内容，请通过内容安全策略（CSP）。使用它，您可以控制对外部站点的访问，包括图像，脚本，字体，样式等。您还可以像警告框一样阻止站点中的不安全内联评估，以防止某些XSS攻击。这是事实上的新标准，许多网站开始实施它。
为了能够防止此类攻击（CSRF攻击），网站还实现了csrf令牌以及随状态变化而变化的形式。即使攻击者以某种方式将请求从site2发送到site1，该请求也不会通过，因为site1的服务器会验证csrf令牌以及该请求，攻击者无法通过该令牌。如果存在来源标头，则其他措施将添加基于来源的验证。
JSONP旨在通过回调允许这种机制。
很抱歉，回答这么长，主题远不止于此。这只是我自己的理解，如果我在任何地方出错，请让我知道。