CREMB集成时为何出现跨域请求失败？

Question

CREMB集成时跨域请求失败，本质是浏览器同源策略（Same-Origin Policy）拦截了前端向非同源CREMB服务端发起的HTTP请求。常见原因包括：① 前端应用（如Vue/React）运行在`http://localhost:3000`，而CREMB后端部署在`https://api.cremb.com:8443`，协议、域名或端口任一不同即触发跨域；② CREMB服务端未正确配置CORS响应头（如缺失`Access-Control-Allow-Origin`、`Access-Control-Allow-Credentials`或预检请求所需的`Access-Control-Allow-Headers`）；③ 前端携带凭据（如Cookie或Authorization头）时，服务端未设置`Access-Control-Allow-Credentials: true`且`Allow-Origin`不能为通配符`*`；④ Nginx/网关层覆盖或遗漏了CORS头。需协同排查前端请求源、服务端CORS策略及中间件配置，优先在CREMB后端显式白名单授权前端域名，并确保预检请求（OPTIONS）被正确响应。

Answer 1

```html

一、现象层：跨域请求失败的典型表现

前端控制台报错：Blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource；或预检请求（OPTIONS）返回 403/404/500，但后续实际请求（GET/POST）根本未发出。此为浏览器同源策略（Same-Origin Policy）在运行时强制拦截的直观信号，非网络连通性问题——curl -v https://api.cremb.com:8443/v1/login 可能完全成功，而浏览器中却静默失败。

二、协议层：同源判定的三大刚性维度

浏览器判定“同源”需同时满足以下三点，缺一不可：

• 协议相同：如 http://localhost:3000 与 https://api.cremb.com:8443 因 http ≠ https 而跨域；
• 域名相同：如 localhost ≠ api.cremb.com（即使 DNS 解析指向同一 IP）；
• 端口相同：如 :3000 ≠ :8443（HTTP 默认 80 / HTTPS 默认 443 亦参与比对）。

任意一项不同即触发跨域限制，且该机制由浏览器内核强制执行，无法通过前端 JavaScript 绕过。

三、协议栈层：CORS 通信全链路关键头字段对照表

请求阶段	关键 Header	服务端必须响应？	典型取值示例
简单请求（GET/POST + text/plain）	Access-Control-Allow-Origin	✅ 必须	http://localhost:3000（不可为 * 若带凭据）
带凭据请求（含 Cookie/Authorization）	Access-Control-Allow-Credentials: true	✅ 必须	true（此时 Allow-Origin 禁用通配符）
预检请求（OPTIONS）	Access-Control-Allow-Headers	✅ 必须	Content-Type, Authorization, X-Request-ID
预检请求（OPTIONS）	Access-Control-Allow-Methods	✅ 必须	GET, POST, PUT, DELETE, OPTIONS

四、架构层：多级代理下的 CORS 头覆盖风险点

Nginx 或 API 网关常成为 CORS 配置的“黑洞”：

• CREMB 后端 Spring Boot 已正确配置 @CrossOrigin(origins = "http://localhost:3000")，但 Nginx 的 location /api/ 块中未透传响应头，甚至主动覆写为 add_header Access-Control-Allow-Origin *;；
• 网关层启用 JWT 鉴权中间件，对 OPTIONS 请求直接返回 200 但未注入任何 CORS 头，导致浏览器因缺失 Allow-Origin 拒绝后续请求；
• Kubernetes Ingress 使用 nginx.ingress.kubernetes.io/cors-allow-origin 注解，但未同步开启 cors-allow-credentials: "true"，造成凭据场景下白名单失效。

五、诊断层：分阶段验证流程图

graph TD A[前端发起请求] --> B{是否携带凭据？
Cookie / Authorization} B -->|是| C[检查服务端是否返回
Access-Control-Allow-Credentials: true
且 Allow-Origin 为具体域名] B -->|否| D[检查 Allow-Origin 是否存在
且值为 * 或匹配源] C --> E[检查预检 OPTIONS 请求
是否返回 200 + 完整 CORS 头] D --> E E --> F{浏览器是否放行？} F -->|是| G[请求进入 CREMB 后端业务逻辑] F -->|否| H[定位缺失头/冲突头位置：
后端代码 → 中间件 → Nginx → Ingress]

六、解决层：生产环境推荐的四级加固方案

1. 后端显式白名单：Spring Boot 中禁用全局 @CrossOrigin，改用细粒度配置：
   @CrossOrigin(origins = {"http://localhost:3000", "https://cremb-fe.prod.com"}, allowCredentials = "true")；
2. 预检请求兜底处理：在 Controller 层添加 OPTIONS 映射，确保不被安全框架拦截：
   @RequestMapping(value = "/**", method = RequestMethod.OPTIONS) 返回 200 + 全量 CORS 头；
3. Nginx 最小化透传：在 proxy_pass 后添加：
   add_header 'Access-Control-Allow-Origin' '$http_origin' always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE' always;
add_header 'Access-Control-Allow-Headers' '$http_access_control_request_headers' always;；
4. 前端开发期代理：Vue CLI 使用 vue.config.js 的 devServer.proxy 将 /api 代理至 https://api.cremb.com:8443，规避开发阶段跨域——但上线前必须移除，不可替代服务端 CORS。

七、高阶陷阱：SSL/TLS 与跨域的隐式耦合

当 CREMB 后端使用自签名证书或证书链不完整时，Chrome 会阻止非安全上下文（http://）向 https:// 发起请求，表现为 CORS 错误而非证书警告。此时需：① 前端开发环境强制启用 http://localhost:3000 的 HTTPS（如使用 mkcert）；② 生产环境确保 CREMB 的 TLS 证书由可信 CA 签发且中间证书完整；③ 检查 Strict-Transport-Security (HSTS) 头是否强制升级，导致本地 HTTP 测试被重定向至 HTTPS 后触发混合内容拦截。

```