API跨域访问的基本概念
在现代Web开发中，API（应用程序编程接口）已成为前后端数据交互的核心，浏览器出于安全考虑，实施了同源策略（Same-Origin Policy），限制了一个源的文档或脚本如何与另一个源的资源进行交互，这种限制虽然有效防止了恶意攻击，但也给合法的跨域API访问带来了挑战，跨域访问（Cross-Origin Resource Sharing，CORS）是指通过特定机制允许不同源之间的资源交互，本文将深入探讨其原理、实现方法及最佳实践。
同源策略与跨域限制
同源策略是浏览器最核心的安全机制之一，它规定一个域下的文档或脚本只能请求与该域同源的资源，所谓“同源”是指协议、域名和端口完全相同。https://example.com/api 与 https://example.com/resource 同源，但与 https://api.example.com 或 http://example.com 不同源，当跨域请求发生时，浏览器会拦截响应,除非目标服务器明确允许这种跨域行为。
| 比较项 | 同源请求 | 跨域请求 |
|---|---|---|
| URL示例 | https://a.com/data 与 https://a.com/info |
https://a.com/data 与 https://b.com/data |
| 浏览器行为 | 直接允许 | 默认拦截，需服务器授权 |
| 安全风险 | 低 | 需通过CORS等机制控制风险 |
CORS机制详解
CORS（Cross-Origin Resource Sharing）是W3C推荐的标准，通过HTTP头部让服务器声明哪些源可以访问资源，其核心是通过Access-Control-Allow-Origin等头部字段控制跨域权限。
简单请求与非简单请求
CORS将请求分为两类：
-
简单请求：满足以下条件的请求被视为简单请求：
- 方法为GET、HEAD或POST。
- POST请求的Content-Type仅限于
application/x-www-form-urlencoded、multipart/form-data或text/plain。 - 请求头中不包含自定义字段（如
X-Custom-Header）。
简单请求会直接发送，浏览器在响应中检查
Access-Control-Allow-Origin头部，若匹配当前源，则允许访问；否则拦截。 -
非简单请求：如PUT、DELETE方法，或Content-Type为
application/json的请求，浏览器会先发送一个“预检请求”（Preflight Request），方法为OPTIONS,携带以下头部：
Access-Control-Request-Method：实际请求方法。Access-Control-Request-Headers：实际请求的自定义头部。
服务器需响应预检请求,返回允许的方法和头部，
Access-Control-Allow-Methods: GET, POST, PUT Access-Control-Allow-Headers: Content-Type, Authorization预检通过后,浏览器才会发送实际请求。
关键CORS头部字段
| 头部字段 | 作用 | 示例值 |
|---|---|---|
| Access-Control-Allow-Origin | 允许访问的源，可设为（允许所有源）或具体域名 | https://example.com 或 |
| Access-Control-Allow-Methods | 允许的HTTP方法 | GET, POST, PUT |
| Access-Control-Allow-Headers | 允许的请求头字段 | Content-Type, Authorization |
| Access-Control-Max-Age | 预检请求结果的缓存时间（秒） | 86400（24小时） |
| Access-Control-Allow-Credentials | 是否允许发送Cookie（需设为true，且Origin不能为） |
true |
跨域访问的解决方案
服务器端配置CORS
最推荐的方法是在服务器端正确配置CORS头部,以常见框架为例：
-
Node.js（Express）：
const express = require('express'); const app = express(); app.use((req, res, next) => { res.header('Access-Control-Allow-Origin', 'https://example.com'); res.header('Access-Control-Allow-Methods', 'GET, POST, PUT'); res.header('Access-Control-Allow-Headers', 'Content-Type'); next(); }); -
Java（Spring Boot）：
@CrossOrigin(origins = "https://example.com", methods = {RequestMethod.GET, RequestMethod.POST}) @RestController public class ApiController { // ... }
代理服务器
若无法修改目标服务器配置，可通过同源代理服务器转发请求，前端请求https://a.com/proxy-api，由服务器转发至https://b.com/api，再将响应返回前端,此方法需注意代理服务器的安全性和性能。
JSONP（仅限GET请求）
JSONP（JSON with Padding）通过动态创建<script>标签实现跨域，但仅支持GET请求，且存在安全风险（如XSS攻击），已逐渐被CORS取代,示例：
function handleResponse(data) {
console.log(data);
}
const script = document.createElement('script');
script.src = 'https://example.com/api?callback=handleResponse';
document.body.appendChild(script);
WebSocket与PostMessage
对于实时通信场景，WebSocket协议不受同源策略限制，而window.postMessage可用于跨窗口、跨iframe通信,需配合事件监听使用。
安全注意事项
虽然CORS解决了跨域问题,但不当配置可能引发安全风险：
- *避免`Access-Control-Allow-Origin:
与凭证共存**：若允许Cookie，必须指定具体源，而非*`。 - 严格限制方法和头部：仅开放必要的HTTP方法和请求头,减少攻击面。
- 验证来源：即使配置了CORS,服务器仍需对请求来源和参数进行合法性校验。
- 敏感操作慎用跨域：涉及用户隐私或关键操作时,建议保持同源策略。
实践案例与调试技巧
案例：前后端分离项目的CORS配置
假设前端部署在https://frontend.com，后端API在https://api.backend.com，需允许前端发送application/json的POST请求：
- 后端响应头需包含：
Access-Control-Allow-Origin: https://frontend.com Access-Control-Allow-Methods: POST Access-Control-Allow-Headers: Content-Type - 前端请求代码：
fetch('https://api.backend.com/data', { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({key: 'value'}) });
调试工具
- 浏览器开发者工具：在“网络”面板中查看请求和响应头部,确认CORS字段是否正确。
- curl命令：模拟预检请求：
curl -X OPTIONS https://api.example.com/data -H "Access-Control-Request-Method: POST" -H "Origin: https://frontend.com"
API跨域访问是现代Web开发中不可避免的问题，理解同源策略、CORS机制及解决方案至关重要，通过合理配置服务器端CORS头部、选择合适的跨域方案（如代理或JSONP），并严格遵守安全规范，既能实现灵活的数据交互，又能保障应用的安全性，随着Web技术的发展，CORS已成为跨域访问的标准实践，开发者需熟练掌握其原理与配置方法,以应对复杂的前后端协作场景。
