公共API如何处理CORS源与JWT？跨域带凭证场景方案问询

一、基础场景：公共API的CORS与JWT配合 #

如果你的公共API用JWT做认证，且不需要携带Cookie类凭证，最省心的处理方式是：

• 将JWT放在请求头的Authorization: Bearer <token>字段中
• 后端设置Access-Control-Allow-Origin: *
• 额外配置Access-Control-Allow-Headers: Authorization，确保浏览器允许携带这个自定义头

这种方式完全避开跨域凭证限制，适合大多数开放API场景。

二、解决*与credentials: "include"的冲突 #

如果API必须用Cookie存储JWT（比如依赖HttpOnly Cookie防XSS），就会遇到浏览器不允许同时设置Access-Control-Allow-Origin: *和credentials: "include"的问题，这时有两种靠谱方案：

1. 动态返回请求的Origin作为允许源 #

后端处理跨域请求时，直接读取请求头里的Origin值，将它作为Access-Control-Allow-Origin的返回值，同时设置Access-Control-Allow-Credentials: true。

• 做基础校验：只允许HTTP/HTTPS协议的Origin，拒绝null或奇怪协议（如file://）的请求，避免恶意伪造
• 对于允许任意用户注册的公共站点，这种方案最灵活，用户的合法HTTP/HTTPS站点都能正常调用API

2. 放弃Cookie，改用请求头存JWT #

直接把JWT放在Authorization头里，无需开启credentials: "include"，这样就能继续用Access-Control-Allow-Origin: *，同时配置Access-Control-Allow-Headers: Authorization。

• 这种方式更适配开放API，跨域限制更少，也不需要处理Origin白名单问题
• 前端存储JWT时尽量用sessionStorage（关闭页面即销毁），避免用localStorage（易受XSS攻击），或封装为内存中的状态管理

三、允许任意用户注册的站点：如何处理源白名单？ #

对于这种场景，固定白名单完全不可行——你不可能提前知晓所有用户的站点域名。最优解是：

• 若用Cookie存JWT，采用「动态返回Origin」的方案；若无需Cookie，直接用「请求头存JWT+*源」的方案
• 若担心动态Origin的风险，可加一层轻量校验：比如检查Origin是否包含有效顶级域名（如.com/.org/.io等），或排除本地IP/localhost之外的非标准域名，但不要做过严限制，避免误伤合法用户

关键注意事项 #

• CORS只是浏览器的同源策略限制，不是安全措施：后端必须严格校验JWT的签名、有效期、权限，不能依赖CORS阻止非法请求
• 若用Cookie存JWT，务必设置HttpOnly、Secure、SameSite=Strict（或Lax）属性，防止XSS和CSRF攻击
• 处理OPTIONS预请求时，返回正确的CORS头，并通过Access-Control-Max-Age设置缓存时间，减少重复OPTIONS请求

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