将 Access-Control-Allow-Origin 配置为星号（*）会导致任何网站都能请求你的接口，且浏览器会拒绝携带 Cookie 等凭据的跨域请求。生产环境应改用动态白名单匹配请求源，并严格限制允许的方法和头部。

命令速用版

若使用 Nginx，可通过 map 模块动态匹配 Origin，避免硬编码星号。

map $http_origin $cors_origin {\n    default "";\n    "~^https?://(example.com|sub.example.net)$" $http_origin;\n}\nserver {\n    location / {\n        if ($cors_origin) {\n            add_header 'Access-Control-Allow-Origin' $cors_origin;\n            add_header 'Access-Control-Allow-Credentials' 'true';\n        }\n    }\n}

若使用 Spring Boot，建议在配置文件中指定允许的来源列表，并开启凭据支持。

为什么会这样

浏览器安全规范强制规定，当响应头 Access-Control-Allow-Origin 为星号时，禁止前端发送凭据。

这是 CORS 标准的硬性限制，旨在防止恶意网站窃取用户登录态。若配置为星号，即使后端支持 Session，前端设置 withCredentials: true 也会被浏览器静默拦截，导致请求失败。同时，开放所有来源意味着任意网站均可通过脚本调用你的接口，增加数据泄露和 CSRF 攻击风险。

分步处理

第一步是梳理业务场景，区分公开接口与需认证接口，公开接口可保留星号，敏感接口必须 whitelist。

第二步是实施动态匹配，在 Nginx 中使用正则校验 $http_origin，或在 Java/Node 后端中间件中读取请求头 Origin 并回写响应头。

第三步是完善预检请求处理，针对 OPTIONS 方法直接返回 204 状态码，并设置合理的 Access-Control-Max-Age 缓存时间。

第四步是限制方法与头部，仅开放必要的 HTTP 方法（如 GET、POST）和请求头（如 Content-Type），避免泛用配置。

怎么验证是否生效

使用浏览器开发者工具的网络面板，查看跨域请求的响应头是否包含具体的域名而非星号。

尝试在前端代码中设置 credentials: include 或 withCredentials: true，确认请求不再被浏览器拦截且控制台无 CORS 报错。对于 Nginx 配置，可使用 curl -H "Origin: https://example.com" -I 命令检查响应头 Access-Control-Allow-Origin 的值是否随请求源变化。

常见坑

切勿同时设置 Access-Control-Allow-Origin: * 与 Access-Control-Allow-Credentials: true，这种组合无效且会被浏览器拒绝。

避免在多个配置块重复添加跨域头，导致响应中出现多个 Access-Control-Allow-Origin 字段引发解析错误。若使用 CDN 或缓存层，需添加 Vary: Origin 头防止缓存污染。

常见问题

公开 API 能否继续使用星号配置？

可以，但前提是该接口完全不涉及用户隐私、登录态或写操作，仅用于获取公开数据。

为什么设置了凭据头请求还是失败？

因为服务端响应头 Origin 为星号，浏览器强制禁止携带凭据，需改为动态匹配具体域名。

多个前端域名如何配置最方便？

使用正则表达式在白名单中匹配多个域名，或通过后端代码动态读取请求头中的 Origin 并回写。

参考来源

• 实战讲解 Nginx 中 Access-Control-Allow-Origin 为*的风险与替代
• 别再乱用 Access-Control-Allow-Origin: *了!Spring Boot/Cloud 中安全配置 CORS 的完整指南
• 修改 response header 中，加入"Access-Control-Allow-Origin:*",这种方案解决跨域会有真正的风险吗
• Nginx"Access-Control-Allow-Origin"安全配置
• 正确配置 Access-Control-Allow-Origin，千万不要设置成*