本文目录 11 个章节
WebGL浏览器前端HTTP请求与跨域资源共享问题
相关概念
Same-Origin Security Policy(SOP)
同源策略 (Same-Origin Policy, SOP)
| 要点 | 说明 |
|---|---|
| 定义 | 浏览器只允许脚本访问与其页面 协议 scheme、主机 host、端口 port 完全一致的资源。默认禁止跨域请求(协议/域名/端口任一不同即跨域) |
| 意义 | 把每一个 Origin 隔离成沙箱,阻止恶意站点窃读或修改另一站点的受信数据(Cookies、表单、银行信息等)。([portswigger.net][2]) |
| 若无 SOP | 任何页面都可在用户登录状态下偷偷:• 读取邮箱 / 网银 API 返回内容 → 隐私泄露• 执行受信操作(转账、删数据)→ CSRF / 账户被盗• 探测内网资产 → 越权扫描 |
作用范围:DOM、localStorage、IndexedDB、Cookies、AJAX/Fetch 等。
XMLHttpRequest / Fetch API 的 CORS 行为
- 默认
mode: "cors"会触发浏览器的同源检查并自动处理预检。 - 若使用
withCredentials = true或credentials: "include",服务器必须返回匹配的Access-Control-Allow-Credentials: true,且Access-Control-Allow-Origin不能是*。
在 SOP 之上如何“合法跨域”——CORS 基本原则
CORS (Cross-Origin Resource Sharing) is a system, consisting of transmitting HTTP headers, that determines whether browsers block frontend JavaScript code from accessing responses for cross-origin requests.
若页面需访问位于不同源(协议、主机或端口不完全一致)的资源,则必须由目标服务端在 HTTP 响应中明确回送 CORS(Cross-Origin Resource Sharing) 相关响应头,授权当前页面的 Origin 进行跨域交互。否则,即使网络链路连通,浏览器也会在收到响应前强制拦截并抛出 “No ‘Access-Control-Allow-Origin’ header” 错误。
| 步骤 | 目的 |
|---|---|
① 浏览器附带 Origin: 请求头 |
告诉目标服务器:“谁在跨域访问你”。 |
| ② 目标服务器返回 CORS 响应头 | 显式声明哪些外域可访问、可用哪些方法、是否允许携带凭证。 |
| ③ 浏览器校验 | 只有当 Access-Control-Allow-Origin 等字段与请求匹配时,才把响应交给前端脚本;否则网络层收到但被浏览器丢弃。 |
结论:配置点始终在目标域(后端 / OSS / CDN),而不是在发起请求的前端。
核心响应头速查表
| Header | 作用 | 示例值 |
|---|---|---|
Access-Control-Allow-Origin |
允许的 Origin | https://yourgame.com 或 * |
Access-Control-Allow-Methods |
允许的 HTTP 方法 | GET,POST,PUT,OPTIONS |
Access-Control-Allow-Headers |
允许的自定义请求头 | Content-Type,Authorization 或 * |
Access-Control-Allow-Credentials |
是否允许 Cookie / 令牌 | true(配合具体 Origin,不能是 *) |
Access-Control-Max-Age |
预检结果缓存秒数 | 3600 |
Access-Control-Expose-Headers |
前端可读的额外响应头 | ETag,x-oss-request-id |
典型配置方案
阿里云 OSS Bucket(控制台示例)
在使用 阿里云 OSS 直传文件的场景中,OSS 服务即为“目标域”,需启用 Bucket-级别的 CORS 规则。推荐采用最小可用授权原则,仅开放实际需要的域名、方法与头部。
| 配置项 | 建议设置 | 说明 |
|---|---|---|
| AllowedOrigin | https://<业务域名>``http://localhost:8080(调试) |
必填;多域名可多行列出,必须带协议与端口 |
| AllowedMethod | POST PUT OPTIONS |
若仅上传,可按需保留 POST/PUT;OPTIONS 为浏览器预检必选 |
| AllowedHeader | * 或列出 Content-Type,Authorization |
建议开发期先放宽为 *,上线前收紧 |
| ExposeHeader | ETag,x-oss-request-id |
供前端读取响应头 |
| MaxAgeSeconds | 3600 |
预检结果在浏览器侧缓存时长 |
| 凭证请求 | 需开启 Access-Control-Allow-Credentials:true(由 OSS 自动返回)并确保 AllowedOrigin 不为 * |
仅当前端使用 withCredentials:true / credentials:'include' 时适用 |
控制台快速配置步骤
- 登录 OSS 控制台 → 选择 Bucket。
- 进入 数据安全 › 跨域设置,点击 创建规则。
- 按上表填写,确认保存后即时生效。
CLI / 自动化示例(ossutil)
<CORSConfiguration>
<CORSRule>
<AllowedOrigin>http://localhost:8080</AllowedOrigin>
<AllowedOrigin>https://yourgame.com</AllowedOrigin>
<AllowedMethod>POST</AllowedMethod>
<AllowedMethod>PUT</AllowedMethod>
<AllowedMethod>OPTIONS</AllowedMethod>
<AllowedHeader>*</AllowedHeader>
<ExposeHeader>ETag</ExposeHeader>
<ExposeHeader>x-oss-request-id</ExposeHeader>
<MaxAgeSeconds>3600</MaxAgeSeconds>
</CORSRule>
</CORSConfiguration>
推送命令:ossutil cors --method put oss://your-bucket cors.xml。([help.aliyun.com][3])
带凭证上传:浏览器需
withCredentials=true,并确保AllowedOrigin为具体域名,OSS 会自动加Access-Control-Allow-Credentials:true。
Nginx 反向代理
location /api/ {
add_header Access-Control-Allow-Origin https://yourgame.com;
add_header Access-Control-Allow-Methods "GET, POST, PUT, OPTIONS";
add_header Access-Control-Allow-Headers "*";
add_header Access-Control-Allow-Credentials true;
if ($request_method = OPTIONS) { return 204; }
}
Node.js / Express
const cors = require('cors');
app.use(cors({
origin: ['https://yourgame.com', 'http://localhost:8080'],
methods: ['GET', 'POST', 'PUT'],
allowedHeaders: ['Content-Type', 'Authorization'],
credentials: true,
maxAge: 3600
}));
注意:
- 如果服务器随意返回
Access-Control-Allow-Origin: *并允许凭证,会暴露会话给任何站点,存在 CSRF/数据泄露风险。 - 因此服务器端 CORS 配置应尽量最小化许可范围。
浏览器与小程序平台的差异
| 特性 | 微信小程序运行时 | 浏览器 (WebGL/H5) |
|---|---|---|
| 网络 API | wx.request() ➜ 原生 TCP/HTTPS,内部实现近似 iOS/Android 的 NSURLSession/OkHttp |
XMLHttpRequest / fetch ➜ 浏览器网络线程 |
是否发送 Origin: 头 |
不发送(所以服务器根本不知道这是谁跨来的域) | 必须发送;浏览器用它比对 Access-Control-Allow-Origin |
| 是否受同源策略 | 不受 ——「跨域」概念对它不存在 | 受 —— 默认禁止跨源,除非服务器通过 CORS 放行 |
| 客户端白名单机制 | 「request 合法域名」写在微信后台,微信本地先检查 | 无 |
| 服务器需否配置 CORS | 不用 | 必须(否则浏览器在收到响应前就拦截) |

小程序平台
微信小游戏运行在微信的环境中,其网络请求是通过微信的客户端(即微信App)发起的,而不是直接由浏览器发起。微信小游戏使用wx.request API发送请求,这个API有以下特点:
- 非浏览器环境:微信小游戏的JavaScript运行环境是微信自己提供的,不是浏览器,因此不会受到浏览器的同源策略(Same-Origin Policy)限制。
- 域名白名单(客户端拦截机制):微信小游戏要求开发者在小程序或小游戏的后台配置请求的合法域名(即request合法域名)。微信客户端在发起请求时会检查目标域名是否在合法域名列表中,如果不在,则请求会被微信客户端阻止。这个机制是微信自己实现的,与浏览器的CORS机制无关。
- 不涉及CORS:由于请求是由微信客户端(原生应用)发起的,而不是浏览器,所以不会触发浏览器的CORS检查。因此,即使阿里云OSS没有配置CORS规则,只要域名在微信的合法域名列表中,请求就能成功。
浏览器平台
遵循W3C规范:浏览器严格执行 CORS标准
在浏览器环境中,当你的Web应用通过XMLHttpRequest或fetch向不同的域(如阿里云OSS的域名)发起请求时,浏览器会强制执行同源策略,并检查CORS响应头。
CORS机制:浏览器会首先发送一个预检请求(OPTIONS请求)到目标服务器(阿里云OSS),询问是否允许来自
http://localhost:8080的请求。服务器必须返回Access-Control-Allow-Origin响应头,并且该头部的值需要包含当前域(或*),浏览器才会允许实际的请求。OSS配置:阿里云OSS作为资源服务器,必须配置CORS规则以响应预检请求,即返回适当的
Access-Control-Allow-Origin等头部。如果没有配置,浏览器就会报错,如你遇到的错误。