Nginx 中用 map 指令动态设置 X-Frame-Options 更灵活安全，支持按路径、Referer、请求头等条件实时控制嵌入策略，需定义在 http 块，配合 add_header 使用，避免与 CSP 的 frame-ancestors 冲突。
直接在 Nginx 中用 map 指令实现动态 X-Frame-Options，是比硬编码更灵活、更安全的方案。它能根据请求路径、域名、来源头或用户角色等条件，实时决定是否允许嵌入、允许谁嵌入，避免全局一刀切带来的兼容性问题。
map 指令的基本写法与作用范围
map 是 Nginx 的变量映射模块，必须定义在 http 块中，不能放在 server 或 location 内。它不执行逻辑判断，只做“输入→输出”的静态映射，轻量且高效。
- 映射源可以是任意内置变量（如
$host、$request_uri、$http_referer）或自定义变量 - 目标值支持字符串、空值（用
""表示）、甚至其他变量（需提前定义） - 映射结果可被后续
add_header或proxy_set_header引用
按请求路径区分策略：登录页严格禁止，后台页同源允许
常见场景是敏感操作页（如 /login、/confirm）必须 DENY，而内部管理页（如 /admin/）只需 SAMEORIGIN。
配置示例：
http {
map $request_uri $xfo_policy {
~^/login "DENY";
~^/confirm "DENY";
~^/admin/ "SAMEORIGIN";
default "SAMEORIGIN";
}
<pre class="brush:php;toolbar:false;">server {
listen 443 ssl;
add_header X-Frame-Options $xfo_policy always;
# 其他配置...
}}
注意：always 参数确保即使返回 302 或 404 等非 200 响应也携带该头，防止绕过。
按 Referer 动态放行可信域名
当需要有限度地支持跨域嵌入（例如 SaaS 平台允许客户官网嵌入仪表盘），可用 $http_referer 匹配白名单。
配置示例：
map $http_referer $xfo_trusted {
~^https?://(dashboard\.customer-a\.com|app\.customer-b\.io)($|/) 1;
default 0;
}
<p>map $xfo_trusted $xfo_policy {
1 "ALLOW-FROM <a href="https://www.php.cn/link/c733f4f772bfa7b8702ccb81887f8333">https://www.php.cn/link/c733f4f772bfa7b8702ccb81887f8333</a> <a href="https://www.php.cn/link/f81715e198d92a9a71609762b7fb2640">https://www.php.cn/link/f81715e198d92a9a71609762b7fb2640</a>";
0 "DENY";
}⚠️ 注意：ALLOW-FROM 已被 Chrome/Firefox 等主流浏览器弃用，实际部署中建议改用 CSP 的 frame-ancestors 替代。若仍需兼容旧系统，此写法仅作过渡。
结合 Cookie 或 Header 实现角色化控制
例如，只有带 X-Internal-User: true 请求头的内网调用才允许嵌入，普通用户一律拒绝。
- 先用
map提取请求头值并归一化 - 再映射为对应策略
配置片段：
map $http_x_internal_user $xfo_role {
"true" "SAMEORIGIN";
default "DENY";
}
<p>server {
add_header X-Frame-Options $xfo_role always;
}这种方式无需后端修改，所有策略集中于 Nginx 层，适合灰度发布或临时风控策略上线。
必须避开的坑
动态头部看似灵活，但几个关键点容易出错：
-
map变量不能在if块中定义，也不能在location中重定义 - 正则匹配要加
~（区分大小写）或~*（忽略大小写），漏写会导致始终走default -
add_header在location中重复出现时，会覆盖上级定义；建议统一在server块设置 - 若同时启用 CSP 的
frame-ancestors，X-Frame-Options 会被浏览器忽略——二者不可共存，应择一使用，推荐优先迁移到 CSP
