Express后端已配置CORS仍报跨域拦截错误的解决方法

报错信息 #

从源站domain1.com向mybackend.com发起的fetch请求被CORS策略拦截：所请求的资源未设置Access-Control-Allow-Origin响应头。如果您仅需要不透明响应，可将请求mode设置为no-cors，在禁用CORS的情况下获取资源。

问题排查与修复 #

结合给出的前后端代码，按优先级排查以下问题：

• 允许跨域的域名列表配置错误
  当前配置的allowedDomains中域名存在多余空格、未写完整源格式的问题：

  // 错误配置
  const allowedDomains = [
      'domain 1',
      'domain 2',
  ];
  

  浏览器发起CORS请求时携带的Origin头是完整源格式，例如https://domain1.com，既不会带空格，也不会省略HTTP/HTTPS协议，服务端用indexOf匹配必然失败，不会返回CORS相关响应头。修正为和实际前端访问源完全一致的格式即可，若前端服务带非默认端口，端口也要一并写上：

  // 正确配置示例
  const allowedDomains = [
      'https://domain1.com',
      'https://domain2.com'
  ];
  

• cors中间件origin校验逻辑错误
  当前配置在校验不通过时直接抛出Error，会触发Express全局错误处理，不会给响应添加任何CORS相关头，最终触发你看到的报错。另外非浏览器客户端（如Postman、curl）发起请求不会携带Origin头，需要根据业务需求决定是否放行。修正后的origin校验逻辑：

  app.use(cors(
       {
       origin: function (origin, callback) {
       // 无origin头的请求按需放行，有origin头则和白名单做精确匹配
       if (!origin || allowedDomains.indexOf(origin) !== -1) {
       callback(null, true);
       } else {
       callback(null, false); // 校验不通过时传false即可，不要直接抛Error
       }
       },
       credentials: true,
       }
  ));
  

  由于请求携带了自定义的Authorization头，浏览器会先发送OPTIONS方法的预检请求，需要单独放行所有OPTIONS请求，避免预检被拦截：

  // 放在cors配置之后、其他路由之前
  app.options('*', cors());
  

• 前端fetch请求配置错误
  当前fetch代码存在URL引号不配对的语法问题，且后端开启了credentials: true配置时，前端跨域请求必须显式添加credentials: 'include'参数，否则无法通过带凭证的CORS校验。修正后的请求代码：

  await fetch('https://mybackend.com/your-api-path' ,{
       method:'GET',
       credentials: 'include', // 对应后端credentials: true配置必须添加
       headers: new Headers({
       'Content-Type':'application/json',
       'Authorization':`Bearer ${token}`,
       }),
       // GET请求不需要传body字段，可直接删除
  })
  

• 其他通用排查点

  • 确认app.use(cors(...))的注册顺序在所有业务路由之前，若注册在路由之后，请求匹配到路由时就会返回响应，不会走cors中间件添加响应头
  • 若服务前部署了Nginx、CDN等反向代理/网关层，需要确认代理层没有覆盖、删除后端返回的CORS相关响应头
  • 确认业务代码、全局错误处理逻辑中没有提前返回响应，导致cors中间件逻辑未执行

内容的提问来源于stack exchange，提问作者EZRA KIPYEGON