09 Helmet 与 CORS 的交互

1. 通常并不冲突

CORS 主要决定跨源页面 JavaScript 能否读取 API 响应；Helmet 设置的一组安全 Header 则影响浏览器如何加载、解释、嵌入和隔离内容。二者职责不同，通常可以同时启用：

app.use(helmet());
app.use(cors(corsOptions));

它们的先后顺序一般不会改变各自 Header，但都应位于路由和错误处理之前。真正的问题通常来自具体策略组合，而不是两个包本身。

假设页面由 https://www.example.com 返回，API 位于 https://api.example.com。

API 的 CORS 即使允许页面源：

Access-Control-Allow-Origin: https://www.example.com

如果页面 HTML 响应上的 CSP 是：

Content-Security-Policy: default-src 'self'; connect-src 'self'

页面仍不能 Fetch 跨域 API。应在页面 CSP 中允许连接目标：

Content-Security-Policy: default-src 'self'; connect-src 'self' https://api.example.com

因此请求需同时通过：

页面 CSP connect-src：页面是否可以发起连接
API CORS：页面是否可以读取跨源响应

Express 只返回 JSON API 时，它在 JSON 响应上加入的 CSP 通常不会反过来约束已经加载的 Nginx 页面。CSP 应重点配置在承载页面的 HTML 响应上。

Cross-Origin-Resource-Policy（CORP）是资源自身声明“哪些站点可以使用我”：

Cross-Origin-Resource-Policy: same-origin

常见值：

如果 Express 返回图片、PDF、字体或预览资源，即使 CORS 放行，严格 CORP 仍可能让某些跨源资源加载失败。纯 JSON Fetch 场景通常首先看 CORS；资源嵌入场景还要检查 CORP。

不要因为一次资源失败就全局关闭 CORP。可只对确实需要跨源公开的资源路由调整：

app.use(
  "/public-assets",
  helmet.crossOriginResourcePolicy({ policy: "cross-origin" }),
  publicAssetsRouter,
);

Cross-Origin-Embedder-Policy: require-corp（COEP）要求页面嵌入的跨源资源明确通过 CORS 或提供兼容的 CORP 策略。它常用于获得跨源隔离能力，例如某些 SharedArrayBuffer 场景。

启用 COEP 后，第三方图片、脚本、字体、WASM 等可能突然失败，因为第三方服务器未提供对应 Header。它不是普通 API 项目的必选开关，应在列出所有页面资源依赖并完成浏览器回归后启用。

Cross-Origin-Opener-Policy（COOP）控制顶层页面与跨源窗口之间的浏览上下文隔离。严格策略可能影响：

COOP 不决定 Fetch 是否通过 CORS。看到登录弹窗异常时，应检查页面响应的 COOP，而不是只调整 API CORS。

下面组合不成立：

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

带 Cookie 的跨源请求必须回明确 Origin。Bearer Token 与 Cookie 凭据机制不要混淆；Bearer Token 需要允许 Authorization 预检，但不一定需要 credentials: true。

现象	优先检查
Fetch Console 提示被 CSP 阻止	页面 CSP `connect-src`
API 200，但 JS 读不到	API CORS Header
跨域图片或字体被阻止	CORP、COEP、CORS、CSP 对应资源指令
OAuth 弹窗无法与原页面通信	COOP
OPTIONS 401	CORS 挂载位置、认证中间件
Cookie 没带上	前端凭据模式、CORS、SameSite、Secure、Domain