SpringCloud 跨域资源共享(cors)到底解决了什么？跨域资源共享(cors)可以放宽浏览器的同源策略，可以通

跨域资源共享(cors)可以放宽浏览器的同源策略，可以通过浏览器让不同的网站和不同的服务器之间通信。

同源策略

同源策略在浏览器安全中是一种非常重要的概念，大量的客户端脚本支持同源策略，比如JavaScript。同源策略允许运行在页面的脚本可以无限制的访问同一个网站（同源）中其他脚本的任何方法和属性。

当不同网站页面（非同源）的脚本试图去互相访问的时候，大多数的方法和属性都是被禁止的。这个机制对于现代web应用是非常重要的，因为他们广泛的依赖http cookie来维护用户权限，服务器端会根据cookie来判断客户端是否合法，是否能发送机密信息。

浏览器要严格隔离两个不同源的网站，目的是保证数据的完整性和机密性。

“同源”的定义：

只要以上三个值是相同的，我们就认为这两个资源是同源的。为了更好的解释这个概念，下面这个表将利用"www.example.com/dir/page.ht…" 这个url作为示例，展示在同源策略控制下不同的结果

下面这个图展示的是：如果不启用cors的时候，恶意脚本发出一个请求之后发生的事情

同源策略对于大型应用有太多的限制，比如有多个子域名的情况现在已经有大量技术可以放宽同源策略的限制，其中有一种技术就是跨域资源共享（CORS) CORS是一种机制，这种机制通过在http头部添加字段，通常情况下，web应用A告诉浏览器，自己有权限访问应用B。

这就可以用相同的描述来定义“同源”和“跨源”操作。

CORS的标准定义是:通过设置http头部字段，让客户端有资格跨域访问资源。

通过服务器的验证和授权之后，浏览器有责任支持这些http头部字段并且确保能够正确的施加限制。主要的头部字段包含：“Access-Control-Allow-Origin”

Access-Control-Allow-Origin: https://example.com

这个头部字段所列的“源”可以以访客的方式给服务器端发送跨域请求并且可以读取返回的文本，而这种方式是被同源策略所阻止的。

默认情况下，如果没有设置“Access-Control-Allow-Credentials”这个头的话，浏览器发送的请求就不会带有用户的身份数据（cookie或者HTTP身份数据），所以就不会泄露用户隐私信息。下面这个图展示一个简单的CORS请求流：

服务器端也会通知客户端是否发送用户的身份数据（cookie或者其他身份数据），如果http头部中的“Access-Control-Allow-Credentials”这个字段被设置“true",那么客户端身份数据就会被发送到目标的服务器上

因为请求会修改数据（通常是GET以外的方法），在发送这些复杂请求之前，浏览器会发送一个”探测“请求

cors预检的目的是为了验证CORS协议是否被理解，预检的OPTION请求包含下面三个字段

这些字段会被浏览器自动的发给服务器端。所以，在正常情况下，前端开发人员不需要自己指定此类请求。

如果服务器允许发送请求，那么浏览器就会发送所需的HTTP数据包。

协议建议，可以简单的利用空格来分隔多个源，比如：

Access-Control-Allow-Origin: https://example1.com https://example2.com

然而，没有浏览器支持这样的语法
通常利用通配符去信任所有的子域名也是不行的，比如：

Access-Control-Allow-Origin: *.example1.com

当前只支持用通配符来匹配域名，比如下面：

Access-Control-Allow-Origin: *

这样配置浏览器将会报错，因为在响应具有凭据的请求时，服务器必须指定单个域，所不能使用通配符。简单的使用通配符将有效的禁用“Access-Control-Allow-Credentials”这个字段。

这些限制和行为的结果就是许多CORS的实现方式是根据“Origin”这个头部字段的值来生成“AccessControl-Allow-Origin”的值

还有一些关于CORS的头部字段，其中一个字段是“Vary"

根据CORS的实施标准，当”Access-Control-Allow-Origin“是被动态产生的话，就要用”Vary: Origin“去指定。

这个头部字段向客户端表明，服务器端返回内容的将根据请求中”Origin“的值发生变化。如果如果未设置此标头，则在某些情况下，它可能会被某些攻击所利用，如在下一节中描述

关注公众号：码农架构，专注于高质量技术文章原创分享与交流，拒绝水文、软文。