主题
Next.js 高级架构
Next.js 如何防御开放重定向和 SSRF？
Next.js 同时拥有浏览器跳转和服务端 fetch 能力，任何用户可控 URL 都要先明确是导航目标还是服务器请求目标。
面试官想考什么
redirect(nextUrl)有什么风险？ 考察开放重定向。- 服务端 fetch 用户传入 URL 为什么危险？ 考察 SSRF。
- 只判断 URL 以公司域名开头够吗？ 考察解析绕过。
- 如何兼顾用户跳转和安全？ 考察白名单和代理设计。
一句话回答
text
用户可控 URL 必须按用途分别校验：导航只允许站内路径或显式域名白名单，服务端 fetch 使用协议、主机、端口、DNS/IP 和响应大小限制，并通过 egress proxy 隔离内网，不能靠字符串前缀判断安全。面试回答详解
1. 开放重定向
text
login?returnTo=/dashboard -> validate same-origin path -> redirect拒绝 //evil.com、不同协议、编码绕过、userinfo、异常端口和不受信任域名。最安全的 returnTo 通常只接受以 / 开头且不以 // 开头的站内路径。
2. SSRF 风险
服务端 fetch 用户提供的 URL 可能访问云 metadata、内网管理面板、localhost 或代理后的服务。需要限制协议、端口、解析后的 IP、重定向次数、DNS 变化、响应大小和超时。
3. 解析策略
使用标准 URL parser，规范化后匹配 host allowlist。不能只用 startsWith("https://trusted.com")，因为 trusted.com.evil、userinfo 和重定向都可能绕过。
4. 代理与隔离
对外部图片、网页和 webhook 使用专门 egress proxy，默认拒绝私网和本地地址；下载内容再做类型、大小、扫描和存储隔离。
5. 观测
记录目标 host 的分类、拒绝原因、重定向次数和响应耗时，不记录完整敏感 URL。安全策略变更要有回滚和阻断开关。
可直接背诵的 30 秒回答
text
开放重定向和 SSRF 都源于用户控制 URL，但防护方式不同。returnTo 只允许站内路径或白名单域名，服务端 fetch 要限制协议、host、端口、解析后的 IP、重定向、超时和响应大小，并尽量经过 egress proxy。不能靠字符串前缀判断，也要做日志和攻击样本测试。扩展知识
URL 安全检查
text
parse -> normalize -> origin/host allowlist
-> port/IP policy -> redirect policy -> timeout/size limit面试官追问链
追问一：只允许 https 就安全了吗？
- 考察点：协议与网络边界。
- 回答方向：不够，HTTPS 也能访问内网；还要限制 host、解析 IP、端口、重定向和响应。
追问二：DNS 解析一次就够吗？
- 考察点：DNS rebinding。
- 回答方向：需要由受控代理解析和连接，或在请求前后校验，避免解析结果变化绕过策略。
追问三：为什么 new URL() 仍然需要业务校验？
- 考察点：解析不等于授权。
- 回答方向：解析器只提供规范化结构，是否允许访问要由业务白名单和网络策略决定。