【.Net技术栈梳理】06-CORS

原创

已于 2025-09-12 22:47:39 修改 · 998 阅读

CC 4.0 BY-SA版权

文章标签：

于 2025-09-09 14:47:06 首次发布

CORS（跨源资源共享）。这是一个在现代 Web 开发中至关重要且常见的概念，尤其对于前后端分离的架构。

1. CORS 是什么？为什么需要它？

要理解 CORS，必须先理解它的对立面：同源策略（Same-Origin Policy）。

定义 : 同源策略是浏览器一个至关重要的安全机制。它规定，一个源（Origin）的文档或脚本，默认情况下无法与另一个源的资源进行交互。
何为“同源”？：如果两个 URL 的协议（Protocol）、域名（Host）、端口（Port）完全相同，则它们属于同源。
- https://example.com/app1 和 https://example.com/app2 -> 同源（协议、域名、端口相同）
- https://example.com 和 http://example.com -> 不同源（协议不同， HTTPS vs HTTP）
- https://example.com 和 https://api.example.com -> 不同源（域名不同）
- https://example.com:8080 和 https://example.com:443 -> 不同源（端口不同）
为何需要？：没有同源策略将会极其危险。一个恶意网站（evil.com）的脚本可以随意读取你在银行网站（your-bank.com）上的数据、伪造你的身份进行操作等。同源策略将不同网站隔离在了各自的“沙箱”中。

然而，合法的跨源需求无处不在：

为了解决这个矛盾，CORS 应运而生。CORS 是一个 W3C 标准，它允许服务器显式地声明哪些外部源有权访问其资源，从而让浏览器放松同源限制。

核心思想：控制权在服务器手中。浏览器只是规则的执行者。服务器通过设置一系列的 HTTP 响应头来告诉浏览器：“我允许来自某某源的请求访问我。”

CORS 请求分为两类：简单请求和预检请求。

满足以下所有条件的请求被视为简单请求：

工作流程：

浏览器照常发出请求（例如，一个 GET 请求），并在请求头中自动添加 Origin，表明请求来自哪个源（如 Origin: https://myapp.com）。
服务器检查 Origin。如果允许，则在响应头中包含 Access-Control-Allow-Origin，其值可以是允许的源（如 Access-Control-Allow-Origin: https://myapp.com）或通配符 *（允许任何源）。
浏览器收到响应后，会检查 Access-Control-Allow-Origin 头。如果它包含了当前请求的源，则允许前端 JavaScript 访问响应内容；否则，浏览器会阻止前端代码访问响应，并在控制台抛出 CORS 错误。

CORS

不满足简单请求条件的请求（例如，使用 PUT, DELETE 方法，或 Content-Type: application/json），浏览器会首先使用 OPTIONS 方法发起一个 预检请求。

工作流程

浏览器发现请求不符合简单请求条件，于是先自动发起一个 OPTIONS 请求到目标服务器。这个请求包含：
- Origin: 请求源
- Access-Control-Request-Method: 实际请求想要使用的方法（如 PUT）。
- Access-Control-Request-Headers: 实际请求想要携带的自定义头部（如 X-Custom-Header）。
服务器响应这个 OPTIONS 请求，通过响应头声明允许的策略：
- Access-Control-Allow-Origin: 允许的源。
- Access-Control-Allow-Methods: 允许的 HTTP 方法（如 GET, POST, PUT）。
- Access-Control-Allow-Headers: 允许的请求头。
- Access-Control-Max-Age: 告诉浏览器可以将这个预检响应缓存多久，避免频繁发送 OPTIONS。
浏览器检查预检响应头。如果所有要求都被服务器批准，浏览器才会接着发出真正的实际请求。否则，就在这一步报错，不会发出实际请求。