API 为什么可以跨域？
跨域问题的本质
| 概念 | 说明 |
|---|---|
| 同源策略 | 浏览器安全机制，要求协议、域名、端口必须完全一致才允许交互 |
| 跨域请求 | 当前端页面与目标API的协议、域名或端口不同时产生的请求 |
浏览器为何限制跨域？
- 安全防护：防止恶意网站通过JavaScript窃取其他网站的Cookie、Session等敏感数据
- 典型攻击场景：CSRF（跨站请求伪造）、XSS（跨站脚本攻击）等
- 限制范围：仅限制浏览器端，服务器之间调用无此限制
CORS跨域解决方案
| 核心机制 | 实现方式 |
|---|---|
| 预检请求 | 对非简单请求发送OPTIONS探测请求 |
| 响应头控制 | 服务器通过Access-Control-*系列响应头授权跨域 |
CORS关键响应头
| 响应头 | 作用 | 示例 |
|---|---|---|
Access-Control-Allow-Origin |
指定允许的源（*表示所有） | Access-Control-Allow-Origin: https://example.com |
Access-Control-Allow-Methods |
允许的HTTP方法 | Access-Control-Allow-Methods: GET,POST |
Access-Control-Allow-Headers |
允许的自定义请求头 | Access-Control-Allow-Headers: x-requested-with |
Access-Control-Expose-Headers |
允许前端获取的响应头 | Access-Control-Expose-Headers: x-custom-header |
工作流程
- 浏览器发送跨域请求时自动携带
Origin标头 - 服务器检测
Origin合法性后返回CORS响应头 - 浏览器验证响应头与请求是否匹配
- 验证通过后正常处理响应数据
其他跨域方案对比
| 方案 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| CORS | HTTP响应头控制 | 现代标准、支持所有HTTP方法 | 需服务器配置 |
| JSONP | 动态创建<script>
| ||
| 服务器代理 | 通过同域服务器中转请求 | 完全控制请求、可加认证 | 增加服务器负载 |
| WebSocket | 长连接协议 | 全双工通信、无跨域限制 | 需特殊协议支持 |
安全注意事项
- 精准配置域名：避免使用通配符，应明确指定允许的域名
- 凭证管理：设置
Access-Control-Allow-Credentials时需配合具体域名 - 方法限制：非必要不开放
PUT/DELETE等危险方法 - Header控制：严格限定允许的自定义请求头
相关问题与解答
Q1：如何配置Nginx服务器支持CORS？
A：在Nginx配置文件中添加CORS响应头：
location /api/ {
add_header 'Access-Control-Allow-Origin' 'https://yourdomain.com';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type';
if ($request_method = 'OPTIONS') {
return 204;
}
}
Q2：JSONP与CORS的主要区别是什么？
A：核心差异对比表：
| 特性 | JSONP | CORS |
|--|--|--|
| 支持方法 | 仅GET | 所有HTTP方法 |
| 安全性 | 存在XSS风险 | 现代安全机制 |
| 浏览器兼容 | IE6+ | IE8+ |
| 实现原理 | 动态脚本加载 | HTTP规范扩展 |
| 响应格式 | 包裹回调函数 |
各位小伙伴们，我刚刚为大家分享了有关“api 为什么可以跨域”的知识，希望对你们有所帮助。如果您还有其他相关问题需要解决，欢迎随时提出哦！
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
