防范OpenRedirect漏洞需确保Nginx重定向仅跳转至预定义可信地址，禁用未过滤的用户变量（如$arg_redirect、$uri）构造Location头，采用map白名单校验，并启用HSTS、升级Nginx版本、避免危险rewrite用法。
要防范 OpenRedirect 漏洞，关键不是禁用重定向，而是确保所有由 Nginx 主动发起的重定向（尤其是通过 rewrite ... redirect 或 return 302/301）只跳转到可信、预定义的地址。Nginx 本身不校验用户输入，因此漏洞根源常在配置逻辑——比如把未过滤的 `$args`、`$uri` 或 `$request_uri` 直接拼入跳转 URL。
禁止使用不可信变量构造跳转地址
最常见错误是用用户可控变量生成 Location 头：
-
危险写法（绝对避免）：
return 302 https://$host$uri;或rewrite ^/login$ https://$host$arg_redirect? permanent;—— 攻击者可传入?redirect=https://evil.com，直接触发开放重定向 -
安全替代方案：如需参数化跳转，必须显式白名单校验。Nginx 原生不支持正则匹配域名，可用
map指令预定义合法目标：
default "";
"https://app.example.com/home" "https://app.example.com/home";
"https://app.example.com/profile" "https://app.example.com/profile";
"https://app.example.com/settings" "https://app.example.com/settings";
}
server {
location = /login {
if ($safe_redirect != "") {
return 302 $safe_redirect;
}
return 302 https://app.example.com/login;
}
}
用 add_header + strict-transport-security 防止协议降级跳转
攻击者可能诱导用户访问 HTTP 页面，再利用 Nginx 的 HTTP→HTTPS 跳转做中转跳向恶意站点。即使你写了 return 301 https://$host$request_uri;，若 `$request_uri` 含恶意 payload，仍可能被滥用。
- 强制启用 HSTS：在 HTTPS server 块中添加
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; - HTTP server 块只做简单协议切换：
return 301 https://$host$request_uri;—— 这里$request_uri不参与外部跳转，仅用于构造同站 HTTPS 地址，风险可控 - 彻底关闭 HTTP 端口（如非必要），从源头消除 HTTP 重定向链路
禁用不安全 rewrite 标志与空字节处理
Nginx ≤1.17.7 存在 rewrite 阶段空字节（%00）解析缺陷，可能导致 Location 头注入或内存泄露，间接扩大 OpenRedirect 利用面。
- 升级至 Nginx 1.29.1+ 或至少 1.20.1+，修复 CVE-2020-12469 等相关漏洞
- 禁用
rewrite ... last在非可信路径中的使用；若必须重写，确保 replacement 字符串为静态值或经map白名单映射后的变量 - 避免在 rewrite 中拼接用户输入：
rewrite ^/go/(.*)$ https://$1 permanent;是高危模式，应替换为固定跳转或服务端逻辑校验
