概述
同源策略（SOP）是Web浏览器强制执行的一种安全策略，用于控制对网站和Web应用程序之间数据的访问。 没有SOP，任何网页都将能够访问其他页面的DOM。 这将使它可以从另一个网页访问潜在的敏感数据，以及在未经用户同意的情况下在其他网页上执行操作。
SOP不是Internet标准或固定规则，而是通用的浏览器安全策略。 不同的浏览器对它的解释不同。 对于不同的技术（例如cookie），它的工作方式也有所不同。 但是，总体思路保持不变：帮助确保没有未经授权的跨站点访问。
源指的是什么
用网络术语来说，来源是网络资源的一组共同特征。 在大多数情况下，源是三个元素的组合：模式（协议），主机名（域/子域）和端口。 因此，由协议 域名 端口标识的所有资源都具有相同的来源。 但是，只要其中之一不相同，现代浏览器（例如Google Chrome或Mozilla Firefox）也会认为这些资源具有不同的来源。 仅在使用Microsoft Internet Explorer的情况下，该端口才不视为来源的一部分。
举例说明
- http://www.example.com/page.html and http://www.example.com/subpage/page2.html HTML
三要素都一样所以是同源的 - http://www.example.com/page.html and https://www.example.com/page.html
是不同的源，因为协议不同。http 和 https - http://www.example.com/page.html and http://example.com/page.html
是不同的源因为子域名不同
http://www.example.com/page.html and http://www.example.com/page.html:8080
是不同的源因为端口不同
同源策略的应用场景
在不同来源的元素之间可能发生交互作用的所有情况下，浏览器都会应用原始检查。 这包括但不限于：
- 例如，JavaScript代码和文档对象模型（DOM），页面无法访问其iframe的内容，除非它们具有相同的来源。
- Cookies，例如，您针对特定站点的会话Cookie不能发送到来源不同的页面。 但是，对于cookie，不评估架构和端口，仅评估域/子域。
- AJAX调用（XmlHTTPRequest）。
同源策略不能完全解决不同源之间的相互作用 以下的一些情况也会有允许跨域的情况。
- 可以在不同的源之间提交表单。 例如，您可以创建跨域链接，也可以跨域提交表单。
- 通常可以在原点之间嵌入。 例如，可以在iframe中使用其他来源的内容（如果X-Frame-Options允许），或者在其他站点中嵌入img，css或脚本。
但是，原点之间的读取通常被阻止。 这通常意味着您可以发送跨域请求，但无法读取回复。
直接看如何解决
在nginx server块添加配置
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Credentials' 'true';
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT,OPTIONS, DELETE';
add_header 'Access-Control-Allow-Headers' 'Authorization,DNT,X-Token,token,TOKEN,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
#access_log logs/host.access.log main;
if ($request_method = 'OPTIONS') {
return 200;
}
有多种方式可以解决跨域问题（放松浏览器安全策略）
http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html
这个是阮大神的总结
Cross-Origin Resource Sharing
CORS 是一种比较好的解决方案。这个模式就是用了预检的请求。也就是正常请求前的 options请求。
跨域资源共享（CORS）是一种HTTP机制，使用HTTP请求头定义源的权限。 使用CORS标头，可以通知浏览器来自其他来源的资源有权访问页面上的资源。
例如
对站点的GET请求可能与声明确切来源的Origin请求标头一起发送（类似于document.domain）：
GET / HTTP/1.1
Host: www.example.com
(...)
Origin: http://example2.com
作为回应如果支持CORS的资源将发送Access-Control-Allow-Origin响应标头：
HTTP/1.1 200 OK
(...)
Access-Control-Allow-Origin: http://example2.com
(...)
Access-Control-Allow-Origin标头可以声明单个源，源列表或通配符（*）。 当然，使用通配符会带来很大的风险，但这取决于Web应用程序开发人员。
在options 请求后就会发送正常的请求。
options 请求
什么是options 请求
1 获取服务器支持的http 请求的方法。
2 检查服务器的性能，例如 ajax 进行跨域请求时候的预检测，需要向另外一个资源发送一个 HTTP OPTIONS的请求头，用来判断实际发送的请求是否安全。这里的options 请求是浏览器的一种策略不是后端发起的
规范要求，对那些可能对服务器数据产生副作用的 HTTP 请求方法（特别是 GET 以外的 HTTP 请求，或者搭配某些 MIME 类型的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求（preflight request），从而获知服务端是否允许该跨域请求。服务器确认允许之后，才发起实际的 HTTP 请求。
“需预检的请求”要求必须首先使用 OPTIONS 方法发起一个预检请求到服务器，以获知服务器是否允许该实际请求。
当请求满足下述任一条件时，即应首先发送预检请求（使用OPTIONS）：
1、使用了下面任一 HTTP 方法：
PUT
DELETE
CONNECT
OPTIONS
TRACE
PATCH
2、人为设置了对 CORS 安全的首部字段集合之外的其他首部字段。该集合为：
Accept
Accept-Language
Content-Language
Content-Type (but note the additional requirements below)
DPR
Downlink
Save-Data
Viewport-Width
Width
3、Content-Type 的值不属于下列之一:
application/x-www-form-urlencoded
multipart/form-data
text/plain