为什么浏览器会阻止跨域请求？
当你在开发前端应用时，是否曾经遇过“Access-Control-Allow-Origin”的错误信息？这并非系统故障，而是浏览器为了保护用户安全所实施的“同源政策（Same-Origin Policy, SOP）”机制。SOP 限制了来自不同来源（协议、域名或端口不同）的网页代码，无法直接读取另一个来源的敏感数据。
同源政策与 CORS 的核心差异
同源政策是浏览器的默认行为，而 CORS（Cross-Origin Resource Sharing）则是为了在安全前提下，让服务器能主动授权特定外部来源访问数据的机制。通过 HTTP 标头的交换，服务器可以明确定义哪些来源是被允许的。
开发者小撇步：CORS 错误通常发生在浏览器端，而非服务器端错误。即便后端 API 运作正常，若缺乏正确的 CORS 设置，浏览器仍会基于安全性拦截响应。
简单请求与预检请求的判断标准
并非所有请求都需要经过复杂的 CORS 握手。根据 HTTP 方法与标头的复杂度，浏览器会将请求分为“简单请求”与“非简单请求”。
| 请求类型 | 特征 | 预检请求（Preflight） |
|---|---|---|
| 简单请求 | GET/POST，且仅使用标准标头 | 不需要 |
| 非简单请求 | 包含自定义标头或 PUT/DELETE 方法 | 需要 (OPTIONS) |
预检请求（Preflight Request）的运作机制
对于非简单请求，浏览器会先发送一个 OPTIONS 请求到服务器，询问“我是否可以发送这个请求？”。服务器收到后，会回传允许的来源、方法与标头。只有在预检通过后，浏览器才会发送实际的请求。
常见的 CORS 设置错误
- Access-Control-Allow-Origin 设置为通配符（*）且允许认证信息（Credentials）。
- 未正确处理 OPTIONS 请求，导致预检失败。
- 缺少必要的 Access-Control-Allow-Headers 设置。
- 将所有来源都开放，导致潜在的跨站攻击风险。
如何正确设置 API 的 CORS 标头
在服务器端设置时，应遵循“最小权限原则”。明确指定允许的 Origin，而非使用星号。对于需要传送 Cookie 的应用，务必将 Access-Control-Allow-Credentials 设置为 true，并确保 Origin 没有被设为 *。
安全性警告：若您的 API 包含敏感用户数据，切勿在生产环境中将 Access-Control-Allow-Origin 设置为 *，这将导致任何网站都能读取您的 API 数据。
现代化 API 设计的安全性考量
除了 CORS，建议同步检视其他安全性标头，如 Content-Security-Policy (CSP) 与 X-Content-Type-Options。通过整合这些机制，能大幅降低 XSS 与跨站请求伪造的风险，确保 Web 应用程序的稳固与可靠。