Nginx CORS配置严禁使用Access-Control-Allow-Origin: *，须白名单校验Origin、按需启用Credentials、拦截非法OPTIONS预检，并协同COEP/COOP/CORP实现跨源隔离。
要防止敏感数据因跨域配置不当而外泄，Nginx 的 CORS 策略不能只加个 Access-Control-Allow-Origin: * 就完事。关键在于：拒绝通配符、白名单校验 Origin、区分凭据场景、拦截非法预检，并与跨源隔离（COEP/COOP/CORP）协同防御。
严格限制 Access-Control-Allow-Origin，禁用通配符
只要接口涉及用户身份、Cookie、Token 或任何敏感操作，Access-Control-Allow-Origin 就绝不能设为 *。否则攻击者可构造恶意页面发起请求，浏览器会放行响应体——数据就泄露了。
- 使用
map指令在http块中定义可信源映射，例如只允许https://app.company.com和https://admin.company.net - 匹配成功才设置响应头：
add_header 'Access-Control-Allow-Origin' $cors_origin always; - 不匹配时
$cors_origin为空，Nginx 不输出该头，浏览器自动拒绝跨域 - 注意协议、端口、子域必须完全一致，
http://和https://视为不同源
按需启用凭据，禁止 ACAC + * 组合
Access-Control-Allow-Credentials: true 表示允许前端携带 Cookie 或认证头，但它的存在会让安全边界急剧收窄——它和 Access-Control-Allow-Origin: * 同时出现时，浏览器直接报错拦截，等于配置失效；若被反射式写入任意 Origin，则构成严重漏洞。
- 仅当业务明确需要登录态透传时才启用该头
- 启用时，
Access-Control-Allow-Origin必须是具体域名（如https://app.company.com），不可动态反射未校验的$http_origin - 前端调用必须显式声明
credentials: 'include'，否则凭证不会发送 - 不需鉴权的公开接口，建议省略该头，默认不携带凭据更安全
精准处理 OPTIONS 预检，避免后端误执行
非简单请求（如 Content-Type: application/json、自定义 Header、PUT/DELETE 方法）会触发浏览器预检。若 Nginx 把 OPTIONS 请求转发给后端，不仅增加负载，还可能绕过你精心写的响应头逻辑。
- 用
if ($request_method = 'OPTIONS') { return 204; }在 location 中提前终止 - 预检响应中必须包含
Access-Control-Allow-Methods和Access-Control-Allow-Headers，但Access-Control-Allow-Credentials若启用，其对应 Origin 也必须是具体值 - 不要在预检响应里返回
Content-Type或其他业务头，保持轻量
叠加跨源隔离策略（COEP/COOP/CORP）防侧信道
CORS 解决“能不能访问”，而 COEP/COOP/CORP 才解决“会不会被滥用”。尤其当页面需使用 SharedArrayBuffer 或测量内存等高敏 API 时，浏览器强制要求跨源隔离。
-
Cross-Origin-Embedder-Policy: require-corp—— 要求所有嵌入资源（JS、图片、iframe）都带合法 CORP 头，否则加载失败 -
Cross-Origin-Opener-Policy: same-origin—— 切断与跨源弹窗/iframe 的 JS 共享环境，防止 opener 泄露 -
Cross-Origin-Resource-Policy: same-site（静态资源）或same-origin（API）—— 从资源端拒绝被非同源页面嵌入或读取 - 三者需同时生效，
self.crossOriginIsolated才为true，敏感能力才可用
