X-Content-Type-Options: nosniff 只能设为 nosniff，不可动态改值；map 仅可用于按请求特征决定是否添加该头，而非修改其值，典型场景包括兼容老旧系统或避免 CDN 冗余。
X-Content-Type-Options: nosniff 是一个静态安全头，它的作用是禁止浏览器对响应内容进行 MIME 类型猜测，从而防止 MIME 嗅探攻击。它本身不依赖请求特征动态变化——无论请求来自哪个域名、携带什么 Content-Type、路径如何，只要服务器决定对某类响应启用该防护，就应统一、稳定地返回 nosniff。
因此，map 指令不能也不应该用于“动态控制 X-Content-Type-Options 的值”（比如有时设为 nosniff，有时设为空或 sniff），因为：
-
X-Content-Type-Options只接受nosniff这一个合法且有意义的值； - 设为空、设为其他字符串（如
sniff）等同于未设置该头，会失去防护效果； - 浏览器完全忽略非法值，不会产生“条件性防护”。
但 map 确实可用于按请求特征差异化决定是否发送该头（即：对某些资源/路径/类型强制加，对其他跳过）。这种用法虽少见，但在特定场景下有合理性。
为什么需要“选择性”加 X-Content-Type-Options？
典型场景包括：
- 后端代理了多个上游服务，其中部分老系统无法正确设置
Content-Type，若强行加nosniff会导致 JS/CSS 加载失败（浏览器拒绝执行text/html响应里的<script></script>）； - 静态资源由 CDN 托管，而 Nginx 仅作反向代理，你希望只对自建服务返回的响应加该头，不对 CDN 回源响应重复添加（避免冗余或冲突）；
- 某些 API 接口返回非标准
Content-Type（如application/vnd.api+json），但前端依赖nosniff保障解析一致性；而管理后台接口返回 HTML，你确认其Content-Type总是准确，可不加。
✅ 关键逻辑：不是“根据请求改头的值”，而是“根据请求决定是否加这个头”。
使用 map 实现条件化添加 X-Content-Type-Options
Nginx 中需配合 map + add_header ... always（或 if + add_header，但 if 在 location 外不推荐）。推荐 map 方式，更清晰、更高效。
步骤一：定义 map 变量，标记是否启用该头
http {
# 根据请求路径判断是否为可信 HTML/JS/CSS 资源
map $request_uri $should_add_nosniff {
~^/api/ 1; # 所有 /api/ 开头的接口都加
~\.(js|css|html)$ 1; # 静态资源文件
default 0;
}
}
?
$request_uri是完整 URI（含 query），也可换用$uri（不含 query）或$http_content_type（需注意：这是请求头，不是响应头，通常不用来控制响应头逻辑）。
步骤二：在 server 或 location 中按变量条件添加头
server {
listen 443 ssl;
server_name example.com;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
# 仅当 $should_add_nosniff == "1" 时添加该头
# 注意：add_header 不支持 if，所以用 map + 变量值触发
add_header X-Content-Type-Options nosniff always;
# ⚠️ 但上面这行是无条件加的 —— 我们需要“条件加”，所以得换个方式：
}
}
⚠️ 上面写法不行：add_header 本身不支持条件渲染。真正可行的是：
✅ 正确做法：用 map 生成一个空/非空值，再用 add_header 引用它（配合 always）
http {
map $should_add_nosniff $nosniff_value {
1 "nosniff";
0 ""; # 空字符串，add_header 会忽略
}
map $request_uri $should_add_nosniff {
~^/api/ 1;
~\.(js|css|html)$ 1;
default 0;
}
}
server {
location / {
proxy_pass http://backend;
# 当 $nosniff_value 非空时才生效；为空则不发送该头
add_header X-Content-Type-Options $nosniff_value always;
}
}
✅
add_header HeaderName $variable always是安全的：若$variable为空，Nginx 不会发送该响应头（验证于 1.22+ 版本）。
更实用的替代方案：按 content-type 或 location 分区控制
多数情况下，你不需要 map，直接用 location 匹配更直观：
location ~ \.(js|css|html|json|xml)$ {
add_header X-Content-Type-Options nosniff always;
proxy_pass http://backend;
}
location /api/ {
add_header X-Content-Type-Options nosniff always;
proxy_pass http://backend;
}
# 其他 location 不加，保持默认行为
location / {
proxy_pass http://backend;
}
这种方式语义清晰、易于维护，适合绝大多数站点。
小结：map 的适用边界
-
map适合跨多个 location 复用同一套匹配逻辑（比如所有 server 块都要按.js/.css统一加头）； - 它不能改变
nosniff的值，只能控制“加或不加”； - 若只是简单路径区分，
location+add_header更直接； -
永远不要试图用 map 动态生成
X-Content-Type-Options: sniff或其他非法值——那等于放弃防护。
安全加固的核心是确定性与一致性，而不是“灵活开关”。对绝大多数现代 Web 应用，建议全站统一启用：
add_header X-Content-Type-Options nosniff always;
仅在明确存在兼容性问题的老系统集成场景中，才考虑用 map 实施有限豁免。
