发布于 由admin

同源策略（Same-Origin Policy）限制了什么？跨域（CORS）的解决方案有哪些？

同源策略与跨域解决方案详解：从原理到实战

各位开发者朋友，大家好！今天我们来深入探讨一个在前端开发中非常关键但又常常被误解的话题——同源策略（Same-Origin Policy） 和 跨域（CORS）的解决方案。无论你是刚入门的小白，还是有一定经验的工程师，这篇文章都将帮助你彻底理解这两个概念的本质、限制范围以及如何优雅地解决跨域问题。

一、什么是同源策略？

同源策略是由浏览器实施的一种安全机制，其核心思想是：“不同源的资源不能随意访问彼此的数据”。这个策略的提出是为了防止恶意网站通过脚本窃取用户敏感信息（比如 Cookie、LocalStorage 等），从而保护用户的隐私和数据安全。

✅ 什么是“同源”？

两个 URL 被认为是“同源”的，必须满足以下三个条件：

条件 必须一致
协议（Protocol） http 或 https
域名（Host） 如 example.com
端口（Port） 如 80、443、3000

🔍 注意：如果其中任意一项不一致，则视为不同源！

示例说明：

URL1: https://api.example.com:8080/data
URL2: https://api.example.com:8080/data   → ✅ 同源
URL3: http://api.example.com:8080/data    → ❌ 不同协议（http vs https）
URL4: https://admin.example.com:8080/data → ❌ 不同域名
URL5: https://api.example.com:9000/data   → ❌ 不同端口

二、同源策略限制了什么？（重点来了）

同源策略并不是一刀切地禁止所有请求，而是对特定类型的交互行为进行限制。以下是它主要限制的内容：

行为类型 是否受限制 说明
XMLHttpRequest / Fetch 请求 ✅ 是 无法发起跨域请求（除非显式允许）
Cookie / LocalStorage / SessionStorage ✅ 是 不同源下无法读取对方的存储内容
DOM 操作（如 iframe 内容） ✅ 是 跨域 iframe 的 DOM 不可访问
脚本注入（script 标签 src） ❌ 否 可以加载跨域 JS 文件（不受同源限制）
图片、CSS、Font 加载 ❌ 否 这些资源可以跨域加载（但可能有其他安全策略）

🧠 关键点：为什么 script 标签可以跨域？

因为 <script src="https://cdn.example.com/script.js"> 是一种“被动加载”，不会主动触发数据读取或修改操作，所以浏览器允许这种行为。这也是 JSONP 实现跨域的基础原理。

三、为什么会出现跨域问题？

现实场景中，我们经常遇到这样的情况：

  • 前端部署在 http://localhost:3000

  • 后端 API 在 https://api.myapp.com

  • 使用 fetch 发起请求时，浏览器会拒绝该请求并报错：

    Access to fetch at 'https://api.myapp.com/users' from origin 'http://localhost:3000' has been blocked by CORS policy.

这就是典型的 CORS（Cross-Origin Resource Sharing）错误 —— 浏览器出于安全考虑阻止了这次请求。

四、CORS 是什么？它是怎么工作的？

CORS 是 W3C 提出的一个标准规范，用于允许服务器声明哪些跨域请求是合法的。它不是浏览器单方面决定是否放行，而是由服务器通过 HTTP 响应头告知浏览器：“我允许这个来源访问我的资源”。

CORS 分为两种类型：

1. 简单请求（Simple Request）

满足以下全部条件即可称为简单请求：

  • 方法只能是 GET、HEAD 或 POST；
  • Content-Type 只能是 application/x-www-form-urlencoded、multipart/form-data 或 text/plain；
  • 不设置自定义 header（如 Authorization、X-Custom-Header）；

✅ 这类请求不需要预检（Preflight），直接发送请求，服务器只需返回正确的响应头即可。

2. 非简单请求（Preflight Request）

只要不符合上述条件，就会触发 预检请求（OPTIONS 请求），浏览器先发一个 OPTIONS 请求询问服务器是否允许本次跨域请求。

例如：

fetch('https://api.myapp.com/users', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer token'
  },
  body: JSON.stringify({ name: 'Alice' })
})

此时浏览器会先发一个 OPTIONS 请求：

OPTIONS /users HTTP/1.1
Origin: http://localhost:3000
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization, Content-Type

服务器必须响应：

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 86400

然后才真正发送 POST 请求。

五、常见的 CORS 解决方案（附代码示例）

下面介绍几种主流的跨域解决方案，适用于不同场景：

方案一：后端配置 CORS（推荐！）

这是最常见、最规范的做法，让服务器明确告诉浏览器：“你可以访问我”。

Node.js + Express 示例：

const express = require('express');
const cors = require('cors');

const app = express();

// 允许特定来源
app.use(cors({
  origin: ['http://localhost:3000'],
  credentials: true // 如果需要携带 cookie
}));

// 或者更宽松的方式（仅用于开发环境）
app.use(cors());

app.get('/api/data', (req, res) => {
  res.json({ message: 'Hello from backend!' });
});

app.listen(8080, () => {
  console.log('Server running on port 8080');
});

Python Flask 示例：

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app, origins=["http://localhost:3000"], supports_credentials=True)

@app.route('/api/data')
def get_data():
    return {"message": "Hello from Flask!"}

if __name__ == '__main__':
    app.run(port=5000)

✅ 优点：安全可控，符合标准，适合生产环境
❌ 缺点：需要修改后端代码，不适合临时调试

方案二：代理服务器（Proxy）——前端常用技巧

如果你控制不了后端，或者不想改后端代码，可以在前端开发阶段使用代理。

Vue CLI / React Dev Server 示例：

Vue CLI (vue.config.js)：
module.exports = {
  devServer: {
    proxy: {
      '/api': {
        target: 'https://api.myapp.com',
        changeOrigin: true,
        pathRewrite: { '^/api': '' }
      }
    }
  }
}

这样你在前端写：

fetch('/api/users') // 实际请求的是 https://api.myapp.com/users
Create React App (package.json)：
{
  "proxy": "https://api.myapp.com"
}

然后调用：

fetch('/users') // 自动转发到 https://api.myapp.com/users

✅ 优点：无需改动后端，开发体验好
❌ 缺点：仅限开发环境，上线需额外处理（如 nginx 反向代理）

方案三：JSONP（老派但有效）

适用于只读场景（GET 请求），利用 <script> 标签无同源限制的特点。

后端实现（Node.js）：

app.get('/api/data', (req, res) => {
  const callback = req.query.callback;
  const data = { message: 'Hello from JSONP!' };

  if (callback) {
    res.setHeader('Content-Type', 'application/javascript');
    res.send(`${callback}(${JSON.stringify(data)})`);
  } else {
    res.json(data);
  }
});

前端调用：

<script>
function handleResponse(data) {
  console.log(data.message); // Hello from JSONP!
}

const script = document.createElement('script');
script.src = 'https://api.myapp.com/api/data?callback=handleResponse';
document.head.appendChild(script);
</script>

✅ 优点：兼容性极强（IE6+）
❌ 缺点：只支持 GET，安全性差（容易 XSS），无法处理复杂请求

方案四：WebSocket（双向通信）

WebSocket 不受同源策略限制（因为它是协议层面的连接），常用于实时应用（聊天室、在线游戏等）。

前端：

const ws = new WebSocket('wss://ws.example.com/chat');

ws.onopen = () => {
  ws.send('Hello Server!');
};

ws.onmessage = (event) => {
  console.log('Received:', event.data);
};

✅ 优点：全双工通信，适合实时场景
❌ 缺点：不是传统 HTTP 请求，适用范围有限

六、常见错误与排查指南

错误类型 常见原因 排查方法
No 'Access-Control-Allow-Origin' header 服务器未设置 CORS 头 查看响应头是否有 Access-Control-Allow-Origin
Invalid CORS request 请求包含非简单方法或 header 检查是否触发 OPTIONS 预检，确认服务器是否正确响应
Blocked by CORS policy Origin 不匹配 检查前端请求地址与服务器允许的 origin 是否一致
Credentials not supported 设置了 credentials 但未启用 添加 credentials: true 并确保服务器允许凭证

💡 Tip：可以用浏览器开发者工具 Network 标签页查看详细响应头，快速定位问题。

七、总结：选择合适的跨域方案

场景 推荐方案 说明
生产环境 + 控制后端 后端配置 CORS 最标准、最安全的方式
开发阶段 + 无法改后端 代理服务器 快速绕过跨域限制，提升开发效率
老旧项目 + 只读接口 JSONP 兼容性好，但不推荐新项目使用
实时通信需求 WebSocket 无需 CORS，适合长连接场景

📌 最佳实践建议：

  • 永远不要在生产环境中禁用 CORS（即设置 Access-Control-Allow-Origin: *）；
  • *避免使用通配符 ``**，尤其当涉及身份认证时（如 JWT、Cookie）；
  • 优先使用 Express.js + cors 中间件 或类似框架插件，简化配置；
  • 合理使用代理，特别是在微服务架构中，可以统一管理跨域逻辑。

结语

同源策略是现代 Web 安全体系的重要基石，而 CORS 是它与实际业务之间的桥梁。理解它们背后的逻辑，不仅能帮你避开坑，还能让你写出更健壮、更安全的应用。

希望这篇讲解能帮你建立起清晰的认知框架。记住一句话：

“跨域不是问题，不懂原理才是问题。”

如果你正在做一个前后端分离的项目，请务必认真对待 CORS —— 它不仅是技术细节，更是你工程素养的体现。

祝你编码愉快，远离跨域烦恼！🚀

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注