服务端必须将Access-Control-Allow-Origin设为具体域名而非*，才能支持带凭证的跨域请求；若前端启用credentials: 'include'，还需设置Access-Control-Allow-Credentials: true并动态校验Origin白名单。

在 JavaScript 的跨域配置中，服务端需明确设置 Access-Control-Allow-Origin 响应头为具体域名（如 https://example.com），而非通配符 *，才能允许指定 Origin 访问。

后端设置指定 Origin（关键步骤）

浏览器发起跨域请求时，会携带 Origin 请求头。服务端必须检查该值，并在响应头中精确返回匹配的域名：

• ✅ 正确示例：
  响应头：Access-Control-Allow-Origin: https://myapp.com
  当前端请求来自 https://myapp.com 时，浏览器放行
• ❌ 错误做法：
  使用 Access-Control-Allow-Origin: * 无法配合凭证（如 cookies、Authorization 头）；若需带凭证，必须写具体域名，且不能用通配符
• ⚠️ 注意大小写和协议/端口： http://myapp.com 和 https://myapp.com 视为不同源；https://myapp.com:8080 也需完全匹配

支持带凭证的跨域（如 cookies 或 token）

若前端设置了 credentials: 'include'，后端除指定 Origin 外，还需额外配置：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 设置 Access-Control-Allow-Credentials: true
• Access-Control-Allow-Origin 不能为 *，必须是确切的 Origin 字符串
• 建议同时设置 Access-Control-Allow-Headers（如 Content-Type, Authorization）和 Access-Control-Allow-Methods（如 GET, POST, PUT）

动态匹配多个可信域名（常见实践）

不推荐硬编码单个域名。生产环境通常维护一个白名单数组，服务端根据请求的 Origin 头动态判断并回写：

立即学习“Java免费学习笔记（深入）”；

• 例如 Node.js（Express）中：

• const allowedOrigins = ['https://myapp.com', 'https://admin.myapp.com'];<br>
  const origin = req.headers.origin;<br>
  if (allowedOrigins.includes(origin)) {<br>
    res.header('Access-Control-Allow-Origin', origin);<br>
    res.header('Access-Control-Allow-Credentials', 'true');<br>
  }

• 务必校验 origin 是否为空或伪造（避免直接反射未验证的 Origin）

前端无需额外配置 Origin

Origin 头由浏览器自动添加，开发者不可手动设置。前端只需确保请求发起的页面地址与服务端允许的域名一致即可。例如：

• 页面运行在 https://myapp.com/dashboard，调用 fetch('https://api.example.com/data')
• 服务端收到的 Origin 就是 https://myapp.com，此时它必须在响应头中返回该值
• 若页面地址是 file:// 或 localhost 端口不匹配，也可能触发跨域失败，需一并纳入白名单测试