1. 同源策略

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

目的就是保护用户信息的安全，防止恶意网站窃取信息。

同源策略对 同源资源 放行，对 异源资源 限制。因此限制造成的开发问题，称之为跨域（异源）问题。

1.1 同源和异源

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

请添加图片描述

站点的定义比“源”更宽松，主要看 顶级域名 + 公共后缀。

如果 顶级域名 + 公共后缀不同 → 跨站。

但是单纯跨站的话，此时浏览器会触发 SameSite Cookie 策略，Cookie 可能不会自动带上。

a.example.com 与 b.example.com → 同站不同源（跨域但不跨站）

a.com 与 b.com → 跨站

1.2 跨域出现的场景

  • 网络通信

    a元素的跳转（href）；加载css、js、图片等（src）；AJAX等等，同源策略会产生不同程度的限制，尤其这里对 ajax 限制非常严格
    在这里插入图片描述

  • JS API

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

  • 存储

    WebStorage、IndexedDB等等

1.3 网络中的跨域

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

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

出现跨域问题保护的是服务端。

2. 解决方案

2.1 CORS

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

CORS，依赖服务端对前端的请求头信息进行放行，不做限制。

Access-Control-Allow-Origin配置成*

请添加图片描述
CORS 机制将请求分为两类：简单请求和预检请求。

2.1.1 简单请求

完整判定逻辑

浏览器为了兼顾安全性和兼容性，规定了一类“不会破坏服务器”的请求作为 简单请求（simple request）。

✅ 设计原因：这些请求在浏览器历史上早已存在（HTML 表单提交就是），所以默认认为对服务器“无害”，可以直接发。

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

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

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

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

  • 如果有Content-Type，必须是下列值中的一个：（axios等库需要时会自动更改Content-Type）

    • text/plain
    • multipart/form-data
    • application/x-www-form-urlencoded

简单请求的交互规范：

  1. 请求头中会自动添加 Origin 字段（就是说Origin 告诉服务器，是哪个源在进行跨域请求）
  2. 服务器响应头中包含 Access-Control-Allow-Origin（服务器收到请求后，如果允许请求跨域访问，需要在响应头添加 Access-Control-Allow-Origin ，该字段包含允许跨域的源）
    在这里插入图片描述
2.1.2 预检请求(preflight)

但如果是 非简单请求（比如 PUT、DELETE、Content-Type: application/json、自定义头），浏览器会在真正请求之前 自动发起一个预检请求（OPTIONS），询问服务端是否允许跨域。

  • 这一步是浏览器内置行为，开发者无法跳过。

目的：

  • 探测：确认目标服务器是否允许跨域访问。
  • 验证：请求头、请求方法是否在服务器允许的范围内。
  • 保护：如果服务器不返回正确的 CORS 响应头，浏览器就会拦截真正的请求，保证安全。
2.1.3 服务器对请求的验证
2.1.3.1 对简单请求的验证

请添加图片描述

2.1.3.2 对预检请求的验证

  1. 发送预检请求

    客户端发起一个带有 Content-Type: application/json 的 POST 请求时：

    OPTIONS /api/data HTTP/1.1
Origin: http://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type

  2. 服务器响应预检请求

    • 服务器需要在响应头里返回相关 CORS 头信息，比如：

      HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true

    • 如果缺少这些头，或者配置不符合请求要求，预检会失败。

  3. 浏览器检查预检响应阶段

    • 浏览器收到响应后，会检查返回的 CORS 头：

      • Access-Control-Allow-Origin 是否允许当前页面的域名
      • Access-Control-Allow-Methods 是否包含即将发起的真实请求方法
      • Access-Control-Allow-Headers 是否包含即将发起的自定义请求头

    • 如果检查通过 → 浏览器再真正发起实际的跨域请求。

    • 如果检查失败 → 浏览器不会发送真正的请求，并在控制台报 CORS 错误。

  4. 服务器允许预检请求后才会发送真实请求（和简单请求一致）
    在这里插入图片描述

2.1.4 两个小问题
2.1.4.1 关于cookie

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

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

// 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 的值为*。这就是为什么不推荐使用*的原因。

2.1.4.2 关于跨域获取响应头

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

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

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

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

2.2 JSONP

JSONP，主要依赖的是script标签不受同源策略影响，src指向某一个接口的地址， 同步需要传递callback回调函数名字， 这样当接口调用成功后， 本地创建的全局回调函数就会执行， 并且接收到数据。不使用img标签的原因是因为img标签无法执行js语句

没有CORS方法的时候。

在这里插入图片描述

image-20230112205613983

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

  • 仅能使用GET请求

  • 容易产生安全隐患

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

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

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

// server.js
const express = require('express');
const bodyParser = require('body-parser');
const cors = require('cors');
const app = express();
app.use(cors());
app.use(bodyParser.json());

// jsonp
app.get('/jsonp', (req, res) => {
  const cbname = req.query.callback || 'callback';
  const data = {
    msg: '来自服务器的消息',
  };
  res.set('content-type', 'application/javascript');
  res.end(`${cbname}(${JSON.stringify(data)})`);
});

// proxy
app.get('/hero', async (req, res) => {
  const axios = require('axios');
  const resp = await axios.get('https://pvp.qq.com/web201605/js/herolist.json');

  // 使用CORS解决对代理服务器的跨域
  res.header('access-control-allow-origin', '*');
  res.send(resp.data);
});

const PORT = 9527;

app.listen(PORT, () => {
  console.log(`server start on port ${PORT}`);
});


// jsonp.html
// jsonp 的封装
const express = require('express');
const bodyParser = require('body-parser');
const cors = require('cors');
const app = express();
app.use(cors());
app.use(bodyParser.json());

// jsonp
app.get('/jsonp', (req, res) => {
  const cbname = req.query.callback || 'callback';
  const data = {
    msg: '来自服务器的消息',
  };
  res.set('content-type', 'application/javascript');
  res.end(`${cbname}(${JSON.stringify(data)})`);
});

// proxy
app.get('/hero', async (req, res) => {
  const axios = require('axios');
  const resp = await axios.get('https://pvp.qq.com/web201605/js/herolist.json');

  // 使用CORS解决对代理服务器的跨域
  res.header('access-control-allow-origin', '*');
  res.send(resp.data);
});

const PORT = 9527;

app.listen(PORT, () => {
  console.log(`server start on port ${PORT}`);
});

动态创建script src指向没有跨域限制， onload

后端返回的数据格式 一定是， test(‘[“111”,“222”,“3333”]’);

前端提前定义好 test这个方法，通过形参就拿到数据了。

jsonp 可以做get请求，无法做post请求（缺点）;

jsonp可以取消吗？不能

2.3 代理

代理访问，前端访问不存在跨域问题的代理服务器，代理服务器再去访问目标服务器（服务器之间没有跨域限制）

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

那如果不是呢？

那就找一个中间人（代理）。

适用场景：生产环境不产生跨域，但开发环境发生跨域。

image-20230115133326930
在这里插入图片描述

3. 如何选择

保持生产环境和开发环境一致。

image-20230115145335319

具体的几种场景：

image-20230115150610750

image-20230115151406797

总结

JSONP（JSON with Padding）

实际工作场合并不会用。

JSONP 是⼀种跨域请求数据的⽅式，它利⽤了<script> 标签不受同源策略限制的特性，可以从不同的域名请求数据。实现原理是在服务端⽣成⼀个 JavaScript 函数，客户端使⽤ <script> 标签请求该函数，服务端返回该函数的调⽤，并将需要传输的数据作为函数参数传⼊。所以jsonp解决的跨域问题具有很明显的不⾜，它只能实现get⽅法的请求。对于post put delete 等其它请求⽆法实现。

// 前端
<script src="https://xxx.com/getUserInfo?
 id=212&callback=getUserInfoRes"></script>
 const getUserInfoRes = ({userName}) => {
    console.log(userName)
 }
 // 后端 这⾥⽤ express 来模拟
app.get('/getUserInfo', (req, res) => {
    const {id, callback} = req.query
    const res = db.query('...', id, (err, res) => {
        res.send(`callback(res.data)`)
    })
 })

CORS（Cross-Origin Resource Sharing）

CORS 跨域资源共享 是⼀种通过添加⼀些 HTTP 头来允许浏览器跨域访问资源的机制，主要是服务端配置。服务端需要在响应头中添加 Access-Control-Allow-Origin 和其他⼀些参数，指示允许哪些域名进⾏跨域请求。

 // index.js http://127.0.0.1:8000
 const http = require('http');
 const urllib = require('url');
 const port = 8000;
 http.createServer(function(req,res){
    // 开启Cors
    res.writeHead(200,{
        // 设置允许跨域的域名，也可设置*允许所有域名
        'Access-Control-Allow-Origin': 'http://127.0.0.1.5500',
        // 跨域允许的请求⽅法，也可以设置*允许所有⽅法
        "Access-Control-Allow-Methods": 'DELETE,PUT,POST,GET,OPIIONS',
        // 允许的header类型
        'Access-Contorl-Allow-Headers': 'Content-Type'
    })
    const { query : { name, age } } = urllib.parse(req.url, true);
    res.end(`${name}今年${age}岁啦！！！`);
 }).listen(port,function(){
    console.log('server is listening on port ' + port);
 })

另外我们可以了解一下浏览器机制，关于预请求和实际请求：
预检请求(Preflight Request):

  1. 对于复杂请求（如使用非简单方法：PUT,DELETE或自定义头），浏览器会先发送一个OPTIONS请求，询问服务器是否允许跨域请求。
  2. 服务器如果同意跨域请求，则返回包含CORS头信息的响应。

实际请求(Actual Request):

  1. 如果预检请求被允许，浏览器会发送实际请求，并且会在请求头中包含一些CORS相关的头信息。
  2. 服务器在响应中包含CORS头信息，这些信息会被浏览器验证。

所以针对于预检请求，还得再后端支持一下：

在这里插入图片描述

以上存在一个 cors 库，专门就是使用 cors 解决跨域问题。

反向代理（本地node服务器 webpack / vite 原理）

开发环境最常用。

反向代理是将客户端的请求转发到真正的服务端，从⽽解决跨域问题。客户端的请求只需要向反向代理服务器发起，由反向代理服务器将请求转发到真正的服务端，最后将响应返回给客户端。

因为本地node服务器并不是浏览器环境，不存在同源策略，所以也不存在跨域问题。

这个过程：

创建开发服务器

  1. 使电Nodejs的http模块创建一个本地开发服务器，监听特定端口，如3000
  2. 这个开发服务器负责处理所有的前端请求，包括静态文件、热模块替换(HMR)、API代理等。

使用http-proxy实现代理：

  1. Vite或者Webpack使用http-proxy(Vite)或http-proxy-middleware(Webapck针对http-proxy进行的二次封装)来创建代理中间件。
  2. 代理中间件会拦截特定路径的请求，并将这些请求转发到目标服务器。

在这里插入图片描述

WebSocket

WebSocket 是⼀种在单个 TCP 连接上进⾏全双⼯通信的协议，可以⽤于跨域通信。由于 WebSocket 协议并不受同源策略的限制，因此可以实现跨域通信。如果需要在客户端和服务端之间进⾏实时通信，WebSocket 是最佳选择。

只是不受同源策略影响，而不能属于是解决跨域问题的方式，总不能把所有接口都变成 socket 通信吧。

// 前端
const socket = new WebSocket('http://www.domain.com:8080')
 socket.addEventListener('open', function () {
    socket.send('...')
 })
 socket.addEventListener('message', function(e) {
    console.log(e.data)
 })
// 后端
 const WebSocket = require('ws')
 const server =  new WebSocket.Server({post: 8080})
 server.addEventListener('connection', function(socket) {
    socket.addEventListener('message', function(res) {
        socket.send(res)
    })
 })

Nginx代理

生产环境部署的时候用的最多的方案。

{
    listen 80
    
    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Headers X-Requested-With;
    add_header Access-Control-Allow-Methods GET,POST,OPTIONS
    location / {
        proxy_pass   http://www.domain.com:8080;
    }
 }

在使用 NGINX 作为反向代理时，解决跨域问题的方法取决于 NGINX 代理的资源类型。以下是两种情况的处理方法：

1. NGINX代理了静态资源和API服务器

在这种情况下，NGINX代理了静态资源（如图片、CSS、JavaScript文件）和API服务器。为了允许跨域访问，通常需要通过 Access-Control-Allow-Origin 头来配置跨域访问。

配置示例：
假设静态资源和API服务器分别在不同的域名下。

server {
    listen 80;
    server_name example.com;

    # 静态资源代理
    location /static/ {
        root /project/static;
        index index.html index.html; # 访问 /static/ 会自动“重定向”到 /project/static/index.html 文件
    }

    # API代理
    location /api/ {
    	rewrite ^/api/(.*)$ /$1 break; # 如果服务器没有 /api 记得重写
        proxy_pass http://api.example.com; # 代理的地址
        
    }
}
2. NGINX仅仅代理了API服务器

如果NGINX只代理API服务器，通常情况下，跨域请求也会通过 Access-Control-Allow-Origin 头来配置。因为只涉及到API访问，静态资源问题不需要考虑。

配置示例：

server {
    listen 80;
    server_name api.example.com;

    location /api/ {
        proxy_pass http://backend-api.example.com;
        
        # 设置CORS头部
        add_header Access-Control-Allow-Origin *;
        add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE, OPTIONS';
        add_header Access-Control-Allow-Headers 'Origin, Content-Type, Accept, Authorization';
        add_header Access-Control-Allow-Credentials true;

        # 处理OPTIONS请求
        if ($request_method = 'OPTIONS') {
            return 204;
        }
    }
}

在这种配置中，NGINX只需要为API请求设置CORS策略。与第一种情况不同，这里不需要处理静态资源的跨域访问，因为所有资源都由API服务器提供。

解决 iframe 跨域问题

跨域问题的出现：

  • 当父页面和 iframe 的来源不同（比如 http://a.com 和 http://b.com），就会出现跨域问题：

    • 父页面不能直接获取 iframe 的 DOM、Cookie、LocalStorage 等数据。
    • iframe 也不能直接操作父页面。

  • iframe.contentWindow.document 无法访问。

  • window.parent.document 无法访问。

  • 不能通过 JS 直接操作 DOM 或获取数据。

✅ (1) document.domain

  • 前提：主域相同，子域不同（如 a.test.com 和 b.test.com）。

  • 父页面和子 iframe 都设置：

    document.domain = "test.com";

  • 这样就可以互相访问了。

  • 局限性：只适合主域相同的场景。

✅ (2) postMessage（推荐）

  • HTML5 提供的安全通信机制，父页面和 iframe 可以安全传递消息。

  • 父页面发送消息：

    const iframe = document.getElementById('myFrame');
iframe.contentWindow.postMessage('hello iframe', 'http://b.com');

  • 子 iframe 接收：

    window.addEventListener('message', (event) => {
  if (event.origin === 'http://a.com') {
    console.log('收到消息:', event.data);
  }
});

  • 优点：安全、灵活，不受同源限制。

  • 缺点：只能传消息，不能直接操作 DOM。

✅ (3) 跨域代理（反向代理）

  • 父页面和 iframe 并非直接跨域通信，而是通过 服务器代理：

    • 比如 http://a.com/proxy 转发到 http://b.com/api，
    • 从而实现同源访问。

  • 常见于 Nginx 反向代理 配置：

    location /api/ {
    proxy_pass http://b.com/api/;
}

4. 总结（面试版回答模板）

iframe 跨域的根本原因是 同源策略 限制，导致父页面和子页面不能互相操作 DOM 或获取数据。
常见解决方案有：

  1. document.domain（主域相同子域不同的情况）；
  2. postMessage（HTML5 推荐的跨域通信方式）；
  3. 反向代理（通过服务器代理解决跨域）；
    其中实际项目里最常用、最安全的是 postMessage。
# 计算机网络
Logo
乐奇 Rokid 开放社区