前端跨域分析及解决办法

摘要：为什么有跨域问题因为浏览器的同源策略，导致了跨域问题的出现。一同源策略什么是同源策略同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。为什么需要同源策略出于安全原因，浏览器限制从脚本内发起的跨源请求。

为什么有跨域问题

因为浏览器的同源策略，导致了跨域问题的出现。

同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。

出于安全原因，浏览器限制从脚本内发起的跨源HTTP请求。 例如XMLHttpRequest遵循同源策略。 这意味着使用这些API的Web应用程序只能从加载应用程序的同一个域请求HTTP资源，除非使用CORS头文件或其他跨域方法。

没有同源策略的两大安全隐患：

针对接口请求
常见的场景为：cookie获取，CSRF攻击：(Cross-site request forgery)跨站请求伪造

One Day，当你兴致勃勃在某宝上准备双11的买买买，网购物车里面各种加，这个时候弹出了你爱豆的新闻，那必须得关注，看一看你家爱豆是不是也要介绍一下另一半，于是就点击连接进去看了，你看的过程中，也许这个网站暗地里就做了些什么不可描述的事情！

比如说由于没有同源策略的限制，它向某宝发起了请求！因为你在登录某宝时“服务端验证通过后会在响应头加入Set-Cookie字段，然后下次再发请求的时候，浏览器会自动将cookie附加在HTTP请求的头字段Cookie中”，这样一来，这个不法网站就相当于登录了你的账号，可以为所欲为了！

针对Dom
假设一个场景需要用户先填写用户名密码等登录信息进行身份验证，才能进行接下来的操作，当你输入用户名密码登录成功后，你的账号密码就被盗了，那酸爽~~~
那这个钓鱼网站做了什么呢？

    // HTML
    
    // JS
    // 由于没有同源策略的限制，钓鱼网站可以直接拿到别的网站的Dom
    let iframe = window.frames["qq"]
    let userInput = iframe.document.getElementById("账号输入框"),
        passInput = iframe.document.getElementById("密码输入框");
    
    //dom都拿到了，账号和密码不就是一件很容易的事情了么~~~

因此同源策略确实能规避一些危险，不是说有了同源策略就安全，只是说同源策略是一种浏览器最基本的安全机制，毕竟能提高一点攻击的成本。其实没有刺不穿的盾，只是攻击的成本和攻击成功后获得的利益成不成正比。

如果两个页面的协议，端口（如果有指定）和域名都相同，则两个页面具有相同的源。

同源的判定：
以http://www.example.com/dir/page.html为例，以下表格指出了不同形式的链接是否与其同源：（原因里未申明不同的属性即说明其与例子里的原链接对应的属性相同）

主域名：由两个或两个以上的字母构成，中间由点号隔开，整个域名只有1个点号，唯一的
子域名：是在主域名之下的域名，域名内容会有多个点号

例如：https://www.baidu.com/
协议：https://
服务器名称：www
主域名：baidu.com
子域名（子域名包括服务器名称www + 主域名baidu.com）：www.baidu.com

目前常用的解决跨域问题的三种方式：

jsonp：只能发送GET请求
iframe + form
CORS:跨域资源共享(Cross-origin resource sharing);

在HTML标签里，一些标签比如script、img这样的获取资源的标签是没有跨域限制的，利用这一点，我们可以这样干：

由上可知JSNOP只能发送GET请求，不能发送POST，本质上通过script标签去加载资源就是GET

看代码

const requestPost = ({url, data}) => {
  // 首先创建一个用来发送数据的iframe.
  const iframe = document.createElement("iframe")
  iframe.name = "iframePost"
  iframe.style.display = "none"
  document.body.appendChild(iframe)
  const form = document.createElement("form")
  const node = document.createElement("input")
  // 注册iframe的load事件处理程序,如果你需要在响应返回时执行一些操作的话.
  iframe.addEventListener("load", function () {
    console.log("post success")
  })

  form.action = url
  // 在指定的iframe中执行form的action url
  form.target = iframe.name
  form.method = "post"
  for (let name in data) {
    node.name = name
    node.value = data[name].toString()
    form.appendChild(node.cloneNode())
  }
  // 表单元素需要添加到主文档中.
  form.style.display = "none"
  document.body.appendChild(form)
  form.submit()

  // 表单提交后,就可以删除这个表单,不影响下次的数据发送.
  document.body.removeChild(form)
}
// 使用方式
requestPost({
  url: "http://localhost:9871/api/iframePost",
  data: {
    msg: "helloIframePost"
  }
})

CORS全称跨域资源共享(Cross-origin resource sharing)，该机制允许Web应用服务器进行跨域访问控制，从而使跨域数据传输得以安全进行。浏览器支持在API容器中（例如XMLHttpRequest或Fetch）使用CORS，以降低跨域HTTP请求所带来的风险。CORS需要客户端和服务器同时支持，目前，所有浏览器都支持该机制（微企即采用这种方式）。

IE 10+ 提供了对规范的完整支持，但在较早版本（8 和 9）中，CORS机制是借由 XDomainRequest 对象完成的。

CORS规范要求，对那些可能对服务器数据产生副作用的HTTP请求方法（特别是GET以外的HTTP请求，或者搭配某些 MIME 类型的POST请求），浏览器必须首先使用OPTIONS方法发起一个预检请求（preflight request），从而获知服务端是否允许该跨域请求。服务器确认允许之后，才发起实际的HTTP请求。在预检请求的返回中，服务器端也可以通知客户端，是否需要携带身份凭证（包括Cookies和HTTP认证相关数据）。

整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。

因此，实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨源通信。

CORS标准允许在下列场景中使用跨域http请求：

由 XMLHttpRequest 或 Fetch 发起的跨域 HTTP 请求。

Web 字体 (CSS 中通过 @font-face 使用跨域字体资源), 因此，网站就可以发布 TrueType

字体资源，并只允许已授权网站进行跨站调用。

WebGL 贴图

使用 drawImage 将 Images/video 画面绘制到 canvas

样式表（使用 CSSOM）

Scripts (未处理的异常)

浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。

使用下列方法之一：
GET
HEAD
POST 

Fetch 规范定义了对 CORS安全的首部字段集合，不得人为设置该集合之外的其他首部字段。该集合为：

Accept

Accept-Language

Content-Language

Last-Event-ID

Content-Type （需要注意额外的限制）

Content-Type 的值仅限于下列三者之一：

text/plain

multipart/form-data

application/x-www-form-urlencoded
只要同时满足以下两大条件，就属于简单请求。

凡是不同时满足上面两个条件，就属于非简单请求。
浏览器对这两种请求的处理，是不一样的。

对于简单请求，浏览器直接发出CORS请求。具体来说，就是在头信息之中，增加一个Origin字段。
下面是一个例子，浏览器发现这次跨源AJAX请求是简单请求，就自动在头信息之中，添加一个Origin字段。

GET /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

上面的头信息中，Origin字段用来说明，本次请求来自哪个源（协议 + 域名 + 端口）。服务器根据这个值，决定是否同意这次请求。

如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应。浏览器发现，这个回应的头信息没有包含Access-Control-Allow-Origin字段（详见下文），就知道出错了，从而抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。

如果Origin指定的域名在许可范围内，服务器返回的响应，会多出几个头信息字段。

Access-Control-Allow-Origin: http://api.bob.com //必填
Access-Control-Allow-Credentials: true //非必填
Access-Control-Expose-Headers: FooBar //非必填
Content-Type: text/html; charset=utf-8

上面的头信息之中，有三个与CORS请求相关的字段，都以Access-Control-开头。

（1）Access-Control-Allow-Origin

该字段是必须的。它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。

（2）Access-Control-Allow-Credentials

该字段可选。它的值是一个布尔值，表示是否允许发送Cookie。默认情况下，Cookie不包括在CORS请求之中。设为true，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。这个值也只能设为true，如果服务器不要浏览器发送Cookie，删除该字段即可。

（3）Access-Control-Expose-Headers

该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。上面的例子指定，getResponseHeader("FooBar")可以返回FooBar字段的值。

withCredentials 属性
上面说到，CORS请求默认不发送Cookie和HTTP认证信息。如果要把Cookie发到服务器，一方面要服务器同意，指定Access-Control-Allow-Credentials字段。

Access-Control-Allow-Credentials: true

另一方面，开发者必须在AJAX请求中打开withCredentials属性。

var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

否则，即使服务器同意发送Cookie，浏览器也不会发送。或者，服务器要求设置Cookie，浏览器也不会处理。

但是，如果省略withCredentials设置，有的浏览器还是会一起发送Cookie。这时，可以显式关闭withCredentials。

xhr.withCredentials = false;

需要注意的是，如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。同时，Cookie依然遵循同源政策，只有用服务器域名设置的Cookie才会上传，其他域名的Cookie并不会上传，且（跨源）原网页代码中的document.cookie也无法读取服务器域名下的Cookie。

2.1 预检请求

非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。

非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。

浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。

下面是一段浏览器的JavaScript脚本。

var url = "http://api.alice.com/cors";
var xhr = new XMLHttpRequest();
xhr.open("PUT", url, true);
xhr.setRequestHeader("X-Custom-Header", "value");
xhr.send();

上面代码中，HTTP请求的方法是PUT，并且发送一个自定义头信息X-Custom-Header。

浏览器发现，这是一个非简单请求，就自动发出一个"预检"请求，要求服务器确认可以这样请求。下面是这个"预检"请求的HTTP头信息。

OPTIONS /cors HTTP/1.1
Origin: http://api.bob.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

"预检"请求用的请求方法是OPTIONS，表示这个请求是用来询问的。头信息里面，关键字段是Origin，表示请求来自哪个源。

除了Origin字段，"预检"请求的头信息包括两个特殊字段。

（1）Access-Control-Request-Method

该字段是必须的，用来列出浏览器的CORS请求会用到哪些HTTP方法，上例是PUT。

（2）Access-Control-Request-Headers

该字段是一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段，上例是X-Custom-Header。

2.2 预检请求的回应

服务器收到"预检"请求以后，检查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后，确认允许跨源请求，就可以做出回应。

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

上面的HTTP回应中，关键的是Access-Control-Allow-Origin字段，表示http://api.bob.com可以请求数据。该字段也可以设为星号，表示同意任意跨源请求。

Access-Control-Allow-Origin: *

如果浏览器否定了"预检"请求，会返回一个正常的HTTP回应，但是没有任何CORS相关的头信息字段。这时，浏览器就会认定，服务器不同意预检请求，因此触发一个错误，被XMLHttpRequest对象的onerror回调函数捕获。控制台会打印出如下的报错信息。

XMLHttpRequest cannot load http://api.alice.com.
Origin http://api.bob.com is not allowed by Access-Control-Allow-Origin.

服务器回应的其他CORS相关字段如下。

Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1728000

（1）Access-Control-Allow-Methods

该字段必需，它的值是逗号分隔的一个字符串，表明服务器支持的所有跨域请求的方法。注意，返回的是所有支持的方法，而不单是浏览器请求的那个方法。这是为了避免多次"预检"请求。

（2）Access-Control-Allow-Headers

如果浏览器请求包括Access-Control-Request-Headers字段，则Access-Control-Allow-Headers字段是必需的。它也是一个逗号分隔的字符串，表明服务器支持的所有头信息字段，不限于浏览器在"预检"中请求的字段。

（3）Access-Control-Allow-Credentials

该字段与简单请求时的含义相同。

（4）Access-Control-Max-Age

该字段可选，用来指定本次预检请求的有效期，单位为秒。上面结果中，有效期是20天（1728000秒），即允许缓存该条回应1728000秒（即20天），在此期间，不用发出另一条预检请求。

2.3 浏览器的正常请求和回应

一旦服务器通过了"预检"请求，以后每次浏览器正常的CORS请求，就都跟简单请求一样，会有一个Origin头信息字段。服务器的回应，也都会有一个Access-Control-Allow-Origin头信息字段。

下面是"预检"请求之后，浏览器的正常CORS请求。

PUT /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.alice.com
X-Custom-Header: value
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

上面头信息的Origin字段是浏览器自动添加的。

下面是服务器正常的回应。

Access-Control-Allow-Origin: http://api.bob.com
Content-Type: text/html; charset=utf-8

上面头信息中，Access-Control-Allow-Origin字段是每次回应都必定包含的。

响应首部中可以携带一个 Access-Control-Allow-Origin 字段，其语法如下:

Access-Control-Allow-Origin:  | *

其中，origin 参数的值指定了允许访问该资源的外域URI。对于不需要携带身份凭证的请求，服务器可以指定该字段的值为通配符，表示允许来自所有域的请求。

例如，下面的字段值将允许来自 http://mozilla.com 的请求：

Access-Control-Allow-Origin: http://mozilla.com

如果服务端指定了具体的域名而非“*”，那么响应首部中的 Vary 字段的值必须包含 Origin。这将告诉客户端：服务器对不同的源站返回不同的内容。

JSONP只支持GET请求，CORS支持所有类型的HTTP请求。JSONP的优势在于支持老式浏览器，以及可以向不支持CORS的网站请求数据。

页面可能会因某些限制而改变他的源。脚本可以将document.domain的值设置为其当前域或其当前域的超级域。如果将其设置为其当前域的超级域，则较短的域将用于后续源检查。
假设http://store.company.com/dir/other.html文档中的一个脚本执行以下语句：

document.domain = "company.com";

这条语句执行之后，页面将会成功地通过对http://company.com/dir/page.html的同源检测（假设http://company.com/dir/page.html将其document.domain设置为company.com，以表明它希望允许这样做 - 更多有关信息，请参阅 document.domain）。然而，company.com不能设置document.domain为othercompany.com，因为它不是 company.com 的超级域

通过添加cross-origin属性即可解决getImageData，toDataURL跨域问题，具体参见canvas跨域