X-Content-Type-Options 不能用 map 动态设置，因其是全局强制型安全头，唯一合法值为 nosniff，必须无条件全覆盖；应使用 add_header 静态配置并加 always 参数。
不能用 map 指令动态设置 X-Content-Type-Options 头。
为什么 map 不适用于 X-Content-Type-Options
X-Content-Type-Options: nosniff 是一个**全局强制型安全响应头**，它的作用是禁止浏览器 MIME 嗅探——这个行为不依赖于请求或响应的具体内容类型，而是一种统一、无条件的安全策略。
map 指令用于根据变量（如 $http_content_type、$sent_http_content_type）预计算新变量（如 $cache_ttl），适用于缓存策略、路由分发、key 构造等需要差异化逻辑的场景。但 X-Content-Type-Options 本身没有“动态取值”需求：它只有唯一合法值 nosniff，且必须对所有响应生效（尤其对 script、style、json 等敏感资源）。
试图按请求特征“有条件地开启 nosniff”，反而会引入漏洞：比如对 text/html 加，对 application/json 不加，就等于在 API 响应中主动放弃防护，违背该头的设计本意。
正确配置方式：统一、静态、全覆盖
应在 http、server 或至少覆盖全部关键 location 的层级，直接使用 add_header 固定注入：
- 推荐放在
http块，确保全站所有响应都带上：
http {
add_header X-Content-Type-Options "nosniff" always;
} - 若需精细控制（如仅对特定后缀资源启用），可放在
location中，但务必覆盖所有可能输出脚本/样式的路径：
location ~ \.(js|json|css|html|htm|xml|svg)$ {
add_header X-Content-Type-Options "nosniff";
} - 必须加
always参数（Nginx 1.7.5+），否则在 304、错误页等非 2xx 响应中会被忽略。
需要动态化的其实是 Content-Type 本身
真正该结合 map 做动态处理的，是响应头中的 Content-Type 值本身，尤其是对用户上传或动态生成的内容：
- 用
map $sent_http_content_type $safe_content_type显式规范常见类型，避免空值或非法值：
map $sent_http_content_type $safe_content_type {
default "application/octet-stream";
"text/html" "text/html; charset=utf-8";
"application/json" "application/json; charset=utf-8";
"image/jpeg" "image/jpeg";
} - 再通过
add_header Content-Type $safe_content_type覆盖上游不规范输出，为X-Content-Type-Options提供可靠依据。
与其他安全头协同加固
X-Content-Type-Options 不应孤立使用。建议与以下头一并配置，形成纵深防御：
-
X-Frame-Options "SAMEORIGIN"：防点击劫持 -
X-XSS-Protection "1; mode=block"：增强 XSS 防御（虽现代浏览器已逐步弃用，但兼容旧版本仍有效） -
Content-Security-Policy：更现代、更全面的资源加载控制（优先级高于X-Content-Type-Options） -
Strict-Transport-Security：强制 HTTPS，防止降级攻击
