【JS|第22期】深入理解跨域

日期：2024年7月6日
作者：Commas
签名：(ง •_•)ง 积跬步以致千里,积小流以成江海……
注释：如果您觉得有所帮助，帮忙点个赞，也可以关注我，我们一起成长；如果有不对的地方，还望各位大佬不吝赐教，谢谢^ - ^
1.01³⁶⁵ = 37.7834；0.99³⁶⁵ = 0.0255
1.02³⁶⁵ = 1377.4083；0.98³⁶⁵ = 0.0006

说在最前面：本文 vue3 的示例代码，在没有另外声名的情况下，均采用 <script setup> 组合式代码风格，风格统一，避免混乱，请各位新老食客放心食用哈 ^ _ ^

文章目录

一、前言
二、同源策略：安全的守护神
- （1）协议（Protocol）
- （2）域名（Domain Name）
- （3）端口号（Port Number）
三、跨域问题的诞生
- （1）分布式架构的发展
- （2）前后端分离的开发模式
- （3）第三方服务集成
- （4）浏览器安全考虑
四、跨域解决方案：从古老到现代
- （1）JSONP：古老而简单
- （2） CORS：现代与安全的典范
- （3） document.domain：跨子域的捷径
- （4）window.postMessage：HTML5的安全通信通道
- （5）服务器代理：后端的桥梁
五、跨域请求的幕后故事
- （1）发起请求
- （2）浏览器检查
- （3）预检请求（如果需要）
- （4）服务器响应预检请求
- （5）浏览器处理预检响应
- （6）发送实际请求
- （7）Chrome 接收到服务器的响应。
六、跨域请求的安全考虑
七、跨域调试：前端开发者的必备技能
八、结语

在这里插入图片描述

一、前言

在当今的 Web 开发中，跨域是一门必修课。今天，我们将一起踏上一段旅程，从同源策略的基础讲起，一路深入，直至掌握跨域的精髓。

二、同源策略：安全的守护神

同源策略，英文全称为 Same-Origin Policy，是浏览器为了保护用户数据安全而设立的一道防线。以下是一些由同源策略导致的限制：

AJAX 请求（通过 XMLHttpRequest ）不能向不同源的服务器发送请求。
不同源下的文档无法读取或修改对方的 DOM。
不同源的 Cookie、LocalStorage 和 IndexedDB 无法互相访问。

所谓“源”，指的是协议、域名和端口号的组合。如果三者中有任何一项不同，即被视为“跨域”。

（1）协议（Protocol）

协议是一套规则，它定义了数据如何在网络上从一个设备传输到另一个设备。它规定了数据传输的格式、错误处理机制、数据交换的时序等。常见的网络协议包括：

HTTP (Hypertext Transfer Protocol)：用于在Web服务器和客户端之间传输网页。
HTTPS (HTTP Secure)：HTTP的安全版本，通过SSL/TLS加密来保护数据传输。
FTP (File Transfer Protocol)：用于文件传输。
SMTP (Simple Mail Transfer Protocol)：用于电子邮件发送。
IMAP/POP3：用于电子邮件接收。
TCP/IP (Transmission Control Protocol/Internet Protocol)：是互联网的基础通信协议，其中TCP负责提供可靠的数据传输，而IP负责将数据包发送到正确的目的地。

（2）域名（Domain Name）

域名是互联网上网站的名称，它是用来代替IP地址的一种更易于记忆的字符串。域名通常由两部分组成：主机名和顶级域（TLD）。例如，在 www.example.com 这个域名中，www 是主机名，example 是二级域名，.com 是顶级域。
域名系统（DNS）负责将域名翻译成对应的IP地址，这样网络浏览器才能找到正确的服务器。

（3）端口号（Port Number）

端口号是一个 16位的数字，用于区分不同的网络服务或进程。当数据包到达服务器时，端口号告诉服务器应该将数据发送到哪个服务或应用程序。一些端口号已经被分配给了特定的服务，例如：

80：用于HTTP服务。
443：用于HTTPS服务。
21：用于FTP服务。
25：用于SMTP服务。

端口号范围从 0到65535，其中 0到1023是系统端口，通常被分配给了知名的互联网服务。高于1023的端口号可以由用户或应用程序自由使用。
在网络地址后面，端口号通常通过一个冒号来指定，例如 www.example.com:8080，这表示访问 www.example.com 的服务器上运行在8080端口号的服务。

三、跨域问题的诞生

同源策略是浏览器的一项重要安全机制，它要求网页中的脚本在执行某些操作时，所访问的资源必须与当前网页的源（协议、域名、端口号）完全相同。同源策略的存在，使得这种跨域请求在默认情况下被浏览器无情地拦截。这正是跨域问题的由来。

跨域问题产生的原因主要有以下几点：

（1）分布式架构的发展

随着互联网应用的规模不断扩大，很多系统采用了分布式架构，不同的功能模块可能部署在不同的域名或端口下。当一个网页需要与其他域名或端口下的资源进行交互时，就会触发同源策略，导致跨域问题。
例如，一个网站的前端页面部署在 example.com，而其数据接口部署在 api.example.com，前端页面向数据接口发送请求时，就会被视为跨域请求。

（2）前后端分离的开发模式

在现代 Web 开发中，前后端分离成为常见的开发模式。前端和后端可能分别运行在不同的服务器和域名上，前端页面需要从不同域名的服务器请求数据，这增加了跨域请求的场景。

（3）第三方服务集成

许多网站需要集成第三方的服务或资源，如地图服务、社交登录等。这些第三方服务通常具有独立的域名，与当前网站的源不同，从而引发跨域问题。

（4）浏览器安全考虑

浏览器为了防止恶意网站通过脚本获取其他网站的敏感信息或进行未经授权的操作，严格限制了跨域访问。
例如，如果没有同源策略的限制，恶意网站可能通过脚本向用户经常访问的银行网站发送请求，获取用户的账户信息等敏感数据。

四、跨域解决方案：从古老到现代

（1）JSONP：古老而简单

JSONP 是跨域解决方案中最早出现的一种，它利用了 <script> 标签不受同源策略限制的特性。服务器返回的数据被包装在一段 JavaScript 函数调用中，前端通过动态创建 <script> 标签来加载并执行这段代码，从而获取数据。不过，JSONP 仅支持 GET 请求，且存在安全风险。

（2） CORS：现代与安全的典范

CORS，即 Cross-Origin Resource Sharing，是一种基于HTTP头的跨域资源共享机制，更是一种更现代、更安全的跨域解决方案。它允许服务器通过设置特定的HTTP响应头来显式地允许某些跨域请求。这些响应头包括 Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers等，它们告诉浏览器哪些源可以访问哪些资源以及可以使用哪些HTTP方法和头字段。与 JSONP 相比，CORS 不仅支持各种 HTTP 方法，还具备更强大的安全性和灵活性。

在这里，还得补充两个概念，简单请求与非简单请求：

简单请求：如果请求满足一定条件（如请求方法为 GET、HEAD 或 POST，且 Content-Type 为 text/plain、multipart/form-data 或 application/x-www-form-urlencoded 之一），则浏览器会直接发送请求，并在响应中检查 CORS 相关的头字段。
非简单请求：对于不满足简单请求条件的请求，浏览器会先发送一个 OPTIONS 请求作为“预检请求”（Preflight Request），询问服务器是否允许跨域请求。服务器在响应中设置CORS 相关的头字段后，浏览器才会发送实际的请求。

（3） document.domain：跨子域的捷径

在某些场景下，两个页面的主域名相同但子域名不同。通过将document.domain设置为共同的主域名，可以绕过同源策略的限制，实现跨子域的数据共享。但是，这种方法只适用于协议和端口号都相同的情况，并且存在一定的安全风险。

（4）window.postMessage：HTML5的安全通信通道

HTML5 引入的window.postMessage方法，允许不同源的窗口之间进行安全的数据传递。它不仅支持跨子域通信，还能够跨越完全不同的域名，为跨域通信提供了新的可能。但是，这种方法需要双方窗口的协作，并且不能用于 Ajax 请求。

（5）服务器代理：后端的桥梁

服务器代理是一种由前端请求同源服务器，再由同源服务器去请求外部服务并返回数据给前端的策略。虽然需要额外的服务器资源，但能够有效解决跨域问题，尤其是在企业级应用中。

五、跨域请求的幕后故事

在 Web 开发中，跨域请求是指从一个域（协议+域名+端口）下的网页向另一个不同域的服务器请求数据的行为。由于浏览器的同源策略限制，默认情况下，JavaScript 不能进行 跨域 HTTP 请求。不过，现代浏览器提供了一些机制来安全地允许跨域请求。以下是使用Chrome浏览器进行跨域请求的一般过程：

（1）发起请求

用户在网页中触发一个跨域请求，例如通过 JavaScript 的 XMLHttpRequest 或 fetch API 向不同源的服务器发送请求。

（2）浏览器检查

Chrome 浏览器接收到请求后，会检查请求的源（协议 + 域名 + 端口）是否与当前页面的源不同。如果不同，确定为跨域请求。

（3）预检请求（如果需要）

对于“非简单请求”，Chrome 会先自动发送一个 OPTIONS 预检请求 到目标服务器。
预检请求的请求头中包含一些信息，如：

Origin 表明请求的来源；
Access-Control-Request-Method 说明实际请求将使用的方法；
Access-Control-Request-Headers 列出实际请求将包含的自定义请求头。

（4）服务器响应预检请求

服务器接收到预检请求后，根据其配置和安全策略决定是否允许该跨域请求。
如果允许，服务器在响应头中添加必要的 CORS 相关信息，如：

Access-Control-Allow-Origin 指定允许访问的源；
Access-Control-Allow-Methods 列出允许的请求方法
Access-Control-Allow-Headers 包含允许的请求头
Access-Control-Max-Age 表示预检请求结果的有效缓存时间。

（5）浏览器处理预检响应

Chrome 接收到预检请求的响应后，检查响应头中的 CORS 信息。
如果响应表明允许跨域请求，并且满足后续实际请求的条件，Chrome 会继续发送实际的跨域请求。

（6）发送实际请求

如果预检请求成功，Chrome 发送实际的跨域请求，请求头中仍然包含 Origin 字段。
服务器处理实际请求并响应
服务器接收到实际请求，进行处理，并在响应头中根据情况添加 CORS 相关信息。
浏览器接收响应

（7）Chrome 接收到服务器的响应。

如果响应头中的 CORS 信息表明请求成功（例如 Access-Control-Allow-Origin 与请求的源匹配），浏览器将响应数据传递给网页中的 JavaScript 代码进行处理。
如果 CORS 信息不满足要求或存在错误，浏览器会阻止 JavaScript 访问响应数据，并可能在控制台中显示错误信息。

六、跨域请求的安全考虑

跨域请求在带来便利的同时，也带来了安全风险。因此，在开发过程中需要特别注意以下几点：

验证请求的合法性：服务器端需要对跨域请求进行验证，确保请求是来自可信的源。
设置合适的 CORS 策略：根据实际需求设置合适的 CORS 策略，避免不必要的跨域访问。
防止CSRF攻击：跨域请求可能会受到 CSRF（跨站请求伪造）攻击的影响，因此需要采取相应的防护措施。

七、跨域调试：前端开发者的必备技能

通过浏览器开发者工具，可以查看网络请求的详细信息，包括请求和响应头，以及服务器返回的错误信息，帮助定位和解决跨域问题。使用开发者工具查看跨域请求数据的步骤：

打开需要调试的网页，按下 F12 键打开开发者工具。
切换到“Network”（网络）选项卡。
当触发跨域请求时，可以在列表中看到相应的请求条目。
点击请求条目，可以查看详细信息，包括：
- Headers（请求头和响应头）：可以查看 Origin 字段确认请求源，以及 Access-Control-Allow-Origin 等 CORS 相关的响应头。
- Preview（预览）：对于一些常见的数据格式（如 JSON、XML），可以直接预览响应的数据内容。
- Response（响应）：查看完整的响应正文。
如果请求失败，在 Console（控制台）选项卡中会显示相关的错误信息，有助于排查问题。

例如，如果您的前端页面从 http://example.com 向 http://anotherexample.com 发送跨域请求，在Network 中找到该请求后，可以查看响应头中是否正确设置了 Access-Control-Allow-Origin: http://example.com 来允许该跨域请求。如果请求失败，控制台可能会显示类似“CORS 策略阻止了访问”的错误信息。