常见的跨域

前端碎碎念

已于 2024-05-29 17:21:03 修改

阅读量263

点赞数

分类专栏：面试文章标签：跨域

于 2019-08-28 17:48:52 首次发布

本文链接：https://blog.csdn.net/zhongqw_00/article/details/100123544

版权

面试专栏收录该内容

111 篇文章 1 订阅

订阅专栏

文章目录

github源码

跨域是什么？

浏览器遵守同源策略，协议、域名、端口三个需要相同才可以进行交换数据。不同源的客户端脚本在没有明确授权的情况下是不允许读写其他网站的资源

跨域：协议、域名、端口有一个不一致就会导致跨域问题

跨域发送的请求会被浏览器处理吗？
跨域请求浏览器可以正常发送服务器也可以正常返回响应，只不过响应被浏览器拦截了而已。如果请求是有返回值的，会被浏览器隐藏掉。

为什么要有同源策略

同源策略限制了，

Cookie、LocalStorage 和 IndexDB 会话存储无法读取。
DOM 无法获得。
AJAX 请求不能发送。

作用：

防止恶意网页可以获取其他网站的本地数据。
防止恶意网站iframe其他网站的时候，获取数据。
防止恶意网站在自已网站有访问其他网站的权利，以免通过cookie免登，拿到数据。

保护用户数据和隐私：
- 浏览器会在同一个环境中加载多个不同来源的网站。这些网站可能会尝试访问彼此的数据。如果没有同源策略，恶意网站可以窃取用户在其他网站上的敏感信息，例如登录凭证、银行账户信息等。
防止跨站脚本攻击（XSS）：
- 同源策略可以防止恶意脚本在一个网页中读取、修改或操纵另一个网页的内容。这样可以有效防止跨站脚本攻击，保护用户的安全。
防止跨站请求伪造（CSRF）：
- 同源策略限制了网页在未明确授权的情况下进行跨站请求，从而防止恶意网站伪造用户的请求，执行操作如转账、修改数据等。
浏览器环境的多重性：
- 浏览器可以同时打开多个标签页或窗口，这些标签页或窗口可以指向不同的网站。没有同源策略的情况下，这些网站之间的互相访问可能导致复杂的安全问题。

客户端应用程序为什么不需要同源策略

独立的运行环境：
- 客户端应用程序通常在独立的环境中运行，与其他应用程序的交互受到操作系统级别的权限控制。它们不需要像浏览器那样处理多个源的并存问题。
严格的权限管理：
- 客户端应用程序的权限通常由操作系统来管理。用户在安装和运行应用程序时，需要明确授权这些应用程序访问特定资源（如文件系统、网络）。这种权限管理机制可以有效地防止未经授权的访问。
不同的信任模型：
- 用户安装客户端应用程序时，通常会执行检查、签名验证，并且用户对应用程序有较高的信任度。相比之下，浏览器中的网页是动态加载的，用户不一定对每个网页都有信任基础。
应用场景的不同：
- 客户端应用程序通常是单一应用，用户不会在同一应用环境中运行多个不同来源的代码。因此，跨来源的安全问题较少。

总结：

同源策略是浏览器为了保护用户数据和隐私、防止跨站攻击等安全问题而设计的。浏览器需要处理多个不同来源的网站同时运行的复杂场景，因此需要同源策略来限制不必要的跨源交互。而客户端应用程序运行在独立的环境中，权限由操作系统管理，信任模型也不同，因此不需要同源策略来进行额外的安全保护。

关于几种跨域的方式的优缺点分析

1.`CORS`

CORS：跨域资源共享

简单请求

简单请求：

浏览器会直接发送AJAX请求，并在HTTP头部添加一个Origin字段，表示请求的来源。
如果服务器接受跨域请求，将在HTTP头部返回一个Access-Control-Allow-Origin字段，表示允许此来源的请求。
如果服务器不允许跨域请求，将返回一个403 Forbidden错误。

GET
POST
HEAD
请求头Accept
请求头Accept-Language
Content-Language
Content-Type的值仅限于下列三者之一：
- text/plain
- multipart/form-data
- application/x-www-form-urlencoded

复杂请求

复杂请求：

先发送一个预检请求OPTION，在HTTP头部添加了一个Access-Control-Request-Method字段，表示实际的请求方法，以及可能存在的Access-Control-Request-Headers字段，表示实际的请求头。
服务器需要在HTTP头部返回一个Access-Control-Allow-Methods字段，表示允许的请求方法，以及一个Access-Control-Allow-Headers字段，表示允许的请求头。
如果服务器不允许跨域请求，将返回一个403 Forbidden错误。

目的：

安全性：复杂请求可能会对服务器产生副作用（例如，修改数据）。通过预检请求，浏览器可以确保服务器显式允许该请求，从而保护用户数据不被恶意使用。
防止 CSRF 攻击：跨域请求带上请求来源，预检请求可以有效地防止跨站请求伪造（CSRF）攻击。通过确认服务器是否允许指定的跨域请求，浏览器可以在实际发送请求之前阻止潜在的攻击行为。

PUT
COntent-type不属于以上三种
戳这里看MDN详解

前端满足复杂请求的条件，后端作一定的配置处理，具体可以查看下图
在这里插入图片描述
如果设置access-control-allow-origin: *会有什么问题吗？
*不允许携带认证头和cookies
结论：

简单请求：不管是否跨域，只要发出去了，一定会到达服务端并被执行，浏览器只会隐藏返回值。
复杂请求：先发预检，预检不会真正执行业务逻辑，预检通过后才会发送真正请求并在服务端被执行。

get、post一定是简单请求吗？

get 请求加上了自定义的请求头，简单请求的跨域请求不会发送预检请求

为什么需要预检请求？

为什么需要预检请求呢？
发出预检请求针对的是非简单请求，这些非简单请求有可能会在服务器进行比较大的运算，增加负载，如果此时cors不通过，就有可能增加了服务器没有必要的运算，如果此时有预检请求，如果不通过，则真实请求不会发出，在一定程度上减少了服务器无效的运算。
为什么简单请求不需要预检呢？
因为简单请求可以由form表单发起，它不是ajax请求，不涉及到跨域和cors问题，可以直接与服务器通信，另外，简单请求大部分上是获取资源比较多，运算也没那么复杂，所以进行一次预检请求就没有必要。

2.`document.domain`

该方式只能用于二级域名相同的情况下，比如 http://a.test.com 和 http://b.test.com 适用于该方式。
只需要给页面添加 document.domain =‘test.com’ 表示二级域名都相同就可以实现跨域。

a.html
在这里插入图片描述
b.html

3.`jsonp`

由于浏览器的<script> | <src> | <ifream> 标签没有跨域限制，网页可以得到从其他来源动态产生的 JSON 数据。JSONP请求一定需要对方的服务器做支持才可以.

优点：简单兼容性好，可用于解决主流浏览器的跨域数据访问的问题。

缺点：是仅支持get方法具有局限性,不安全可能会遭受XSS攻击。

function jsonp(req) {
    var script = document.createElement('script');
    var url = req.url + '?callback=' + req.callback.name;
    script.src = url;
    document.getElementsByTagName('head')[0].appendChild(script);
}

4.`nginx`

实现原理类似于Node中间件代理，需要你搭建一个中转nginx服务器，用于转发请求。

使用nginx反向代理实现跨域，是最简单的跨域方式。只需要修改nginx的配置即可解决跨域问题，支持所有浏览器，支持session，不需要修改任何代码，并且不会影响服务器性能。

在这里插入图片描述

5.`postMessage`

允许来自不同源的脚本采用异步方式进行有限的通信，可以实现跨文本档、多窗口、跨域消息传递。

页面和其打开的新窗口的数据传递
多窗口之间消息传递
页面与嵌套的iframe消息传递
上面三个场景的跨域数据传递

6.`websocket`

Websocket是HTML5的一个持久化的协议，它实现了浏览器与服务器的全双工通信，同时也是跨域的一种解决方案。WebSocket和HTTP都是应用层协议，都基于 TCP 协议。但是 WebSocket 是一种双向通信协议，在建立连接之后，WebSocket 的 server 与 client 都能主动向对方发送或接收数据。同时，WebSocket 在建立连接时需要借助 HTTP 协议，连接建立好了之后 client 与 server 之间的双向通信就与 HTTP 无关了。

a.html
在这里插入图片描述
server.js