阿卡不拉

Appearance

同源策略及跨域问题 ✨ ​

要点速览

  • 同源策略：保护浏览器安全，默认限制不同源的文档与脚本交互。
  • 场景分类：网络通信（标签/资源/AJAX）、JS API（window/iframe）、存储（WebStorage/IndexedDB）。
  • 浏览器限制原则：标签跨域限制轻、AJAX 跨域限制重。
  • 正统方案：CORS；历史方案：JSONP；绕过方案：代理（同源中转）。
  • 关键细节：简单请求与预检请求判定；凭证携带（credentials）、Access-Control-* 响应头设置、预检缓存、响应头白名单。

同源策略是一套浏览器安全机制，当一个源的文档和脚本，与另一个源的资源进行通信时，同源策略就会对这个通信做出不同程度的限制。（对不同源的文档或者脚本的交互进行限制）

简单来说，同源策略对 同源资源 放行，对 异源资源 限制

因此限制造成的开发问题，称之为跨域（异源）问题

同源和异源 ​

源(origin) = 协议 + 域名 + 端口

例如:

https://study.duyiedu.com/api/movie的源为https://study.duyiedu.com

http://localhost:7001/index.html的源为http://localhost:7001

两个 URL 地址的源完全相同，则称之为同源，否则称之为异源（跨域）

image-20230112163455982

跨域出现的场景 ​

跨域可能出现在三种场景：

  • 网络通信

    a 元素的跳转；加载 css、js、图片等；AJAX 等等，页面的源与访问的源不同

  • JS API

    window.open、window.parent、iframe.contentWindow等等

  • 存储

    WebStorage、IndexedDB等等

对于不同的跨域场景，以及每个场景中不同的跨域方式，同源策略都有不同的限制。

本文重点讨论网络通信中 AJAX 的跨域问题。

网络中的跨域 ​

当浏览器运行页面后，会发出很多的网络请求，例如 CSS、JS、图片、AJAX 等等

请求页面的源称之为页面源，在该页面中发出的请求称之为目标源。

当页面源和目标源一致时，则为同源请求，否则为异源请求（跨域请求）

image-20230112163616513

浏览器如何限制异源请求？ ​

浏览器出于多方面的考量，制定了非常繁杂的规则来限制各种跨域请求，但总体的原则非常简单：

  • 对标签发出的跨域请求轻微限制
  • 对AJAX发出的跨域请求严厉限制

image-20230112201027855

解决方案 ​

CORS ​

CORS（Cross-Origin Resource Sharing）是最正统的跨域解决方案，同时也是浏览器推荐的解决方案。

CORS 是一套规则，用于帮助浏览器判断是否校验通过。

image-20230112202539003

CORS 的基本理念是：

  • 只要服务器明确表示允许，则校验通过
  • 服务器明确拒绝或没有表示，则校验不通过

所以，使用 CORS 解决跨域，必须要保证服务器是「自己人」

兼容与前提

  • CORS 需要目标服务器按规范返回响应头；第三方不可控服务通常无法满足，需改为代理或后端转发。
  • 现代浏览器均支持 CORS；老旧环境可考虑后端降级或特殊方案（不推荐）。

请求分类 ​

CORS 将请求分为两类：简单请求（simple request）和预检请求（preflight request）。

对不同种类的请求它的规则有所区别。

所以要理解 CORS，首先要理解它是如何划分请求的。

简单请求 ​

完整判定逻辑：https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests

简单来说，只要全部满足下列条件，就是简单请求：

  • 请求方法是GET、POST、HEAD之一

  • 头部字段满足 CORS 安全规范，详见 W3C

    浏览器默认自带的头部字段都是满足安全规范的，只要开发者不改动和新增头部，就不会打破此条规则

  • 如果有Content-Type，必须是下列值中的一个

    • text/plain
    • multipart/form-data
    • application/x-www-form-urlencoded
一些常见的  Content-Type  类型
  • application/json：表示发送的是 JSON 格式的数据。常用于 RESTful API。
  • application/x-www-form-urlencoded：表示表单数据，常用于标准的 HTML 表单提交。数据以键值对形式编码，例如 key1=value1&key2=value2。
  • multipart/form-data：用于表单中包含文件上传时。数据会被分成多个部分，每个部分可以有不同的内容类型。
  • text/plain：表示发送的是纯文本数据。
  • text/html：表示发送的是 HTML 文档。
  • application/xml：表示发送的是 XML 格式的数据。
  • application/octet-stream：表示发送的是二进制数据，通常用于文件下载。
  • image/jpeg、image/png、image/gif：表示发送的是特定格式的图像文件。
预检请求(preflight) ​

只要不是简单请求，均为预检请求

预检请求目的

浏览器先发 OPTIONS 预检，确认服务器允许的源、方法与自定义头；通过后再发真实请求。

练习 ​
js
// 下面的跨域请求哪些是简单请求，哪些是预检请求

// 1
fetch("https://douyin.com"); // 简单请求

// 2
fetch("https://douyin.com", {
  headers: {
    a: 1, // 预检请求
  },
});

// 3
fetch("https://douyin.com", {
  method: "POST",
  body: JSON.stringify({ a: 1, b: 2 }), // 简单请求
});

// 4
fetch("https://douyin.com", {
  method: "POST",
  headers: {
    "content-type": "application/json", // 预检请求
  },
  body: JSON.stringify({ a: 1, b: 2 }),
});

对简单请求的验证 ​

image-20230112204546583

对预检请求的验证 ​

  1. 发送预检请求

image-20230112204634493

  1. 发送真实请求（和简单请求一致）
服务器端示例（Express）
js
const express = require("express");
const app = express();

app.use((req, res, next) => {
  const origin = req.headers.origin;
  res.header("Access-Control-Allow-Origin", origin); // 指定允许的源
  res.header("Vary", "Origin"); // 缓存区分不同 Origin
  res.header("Access-Control-Allow-Credentials", "true"); // 允许凭证
  res.header("Access-Control-Expose-Headers", "authorization, x-custom");

  if (req.method === "OPTIONS") {
    res.header("Access-Control-Allow-Methods", "GET,POST,PUT,DELETE");
    res.header(
      "Access-Control-Allow-Headers",
      "content-type, authorization, x-custom"
    );
    res.header("Access-Control-Max-Age", "600"); // 预检结果缓存 10 分钟
    return res.sendStatus(204);
  }
  next();
});

app.get("/api/data", (req, res) => {
  res.json({ ok: true });
});

app.listen(3000);

默认情况下，AJAX 的跨域请求并不会附带 cookie，这样一来，某些需要权限的操作就无法进行

不过可以通过简单的配置就可以实现附带 cookie

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

// fetch api
fetch(url, {
  credentials: "include",
});

这样一来，该跨域的 AJAX 请求就是一个附带身份凭证的请求

当一个请求需要附带 cookie 时，无论它是简单请求，还是预检请求，都会在请求头中添加cookie字段

而服务器响应时，需要明确告知客户端：服务器允许这样的凭据

告知的方式也非常的简单，只需要在响应头中添加：Access-Control-Allow-Credentials: true即可

对于一个附带身份凭证的请求，若服务器没有明确告知，浏览器仍然视为跨域被拒绝。

另外要特别注意的是：对于附带身份凭证的请求，服务器不得设置 Access-Control-Allow-Origin 的值为*。这就是为什么不推荐使用*的原因

凭证请求与 *

携带凭证（Cookie、HTTP 认证、客户端证书）的请求必须返回具体 Origin 值，且设置 Access-Control-Allow-Credentials: true；* 会被浏览器直接判定为不允许。

细节 2 - 关于跨域获取响应头 ​

在跨域访问时，JS 只能拿到一些最基本的响应头，如：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma，如果要访问其他头，则需要服务器设置本响应头。

Access-Control-Expose-Headers头让服务器把允许浏览器访问的头放入白名单，例如：

Access-Control-Expose-Headers: authorization, a, b

这样 JS 就能够访问指定的响应头了。

js
fetch("/api/data", { credentials: "include" })
  .then((res) => {
    console.log(res.headers.get("authorization"));
    console.log(res.headers.get("x-custom"));
    return res.json();
  })
  .then((data) => console.log(data));

JSONP ​

在很久很久以前...并没有 CORS 方案

image-20230112205454350

在那个年代，古人靠着非凡的智慧来解决这一问题：由于 <script> 标签不受同源策略限制，可以加载任何域的脚本，并且脚本加载完成后会立即执行其内容，由此...

整个流程描述如下程：

  1. 浏览器解析并加载动态添加的 <script> 标签
  2. 向 https://api.example.com/data?callback=handleResponse 发起请求
  3. 服务器返回文本内容：handleResponse({...})
  4. 浏览器将其作为 JavaScript 代码立即执行
  5. 执行过程调用预先定义的 handleResponse 函数
  6. 客户端在回调函数中处理数据
js
// JSONP 核心代码
// 1. 客户端定义回调函数（全局作用域）
function handleResponse(data) {
  console.log("收到数据:", data);
  document.getElementById("result").innerText = JSON.stringify(data);
  // 清理工作
  document.body.removeChild(script);
}

// 2. 创建动态脚本标签
const script = document.createElement("script");
script.src = "https://api.example.com/data?callback=handleResponse";
document.body.appendChild(script);

// 3. 服务器响应（返回可执行代码）
// 返回内容：handleResponse({"name":"John","age":30,"city":"New York"})

虽然可以解决问题，但 JSONP 有着明显的缺陷：

  • 仅能使用 GET 请求
  • 容易产生安全隐患

    恶意攻击者可能利用callback=恶意函数的方式实现XSS攻击

  • 容易被非法站点恶意调用

因此，除非是某些特殊的原因，否则永远不应该使用 JSONP

使用场景与风险

  • 仅限 GET；返回可执行脚本，存在 XSS 风险；不可携带凭证与复杂头部。
  • 如必须使用，务必校验 callback 名称并进行白名单控制，避免注入。

代理 ​

CORS 和 JSONP 均要求服务器是「自己人」

那如果不是呢？

image-20230112210551647

那就找一个中间人（代理服务器），浏览器请求同源的代理服务器，代理服务器再请求目标服务器从而绕过浏览器的同源策略。

开发/生产常见方案
  • 开发：前端构建工具内置代理（如 vite.config.js 的 server.proxy）。
  • 生产：反向代理（Nginx）或后端网关转发，统一鉴权与 CORS。
js
// Vite 代理示例
export default {
  server: {
    proxy: {
      "/api": {
        target: "https://target.example.com",
        changeOrigin: true,
        rewrite: (p) => p.replace(/^\/api/, ""),
      },
    },
  },
};

image-20230115133326930

比如，前端小王想要请求获取王者荣耀英雄数据，但直接请求腾讯服务器会造成跨域

image-20230115133732560

由于腾讯服务器不是「自己人」，小王决定用代理解决

image-20230115133817554

如何选择 ​

最重要的，是要保持生产环境和开发环境一致

下面是一张决策图

image-20230115145335319

具体的几种场景

image-20230115150610750

image-20230115151406797