Next.js SSR安全机制踩坑记录
最近在为一个Next.js项目构建SSR安全防护体系时，踩了不少坑，分享一下血泪史。
问题发现
最初以为Next.js默认的安全机制够用，直到测试阶段发现以下风险点：
- Server Side Request Forgery (SSRF) - 通过恶意请求访问内部服务
- Path Traversal - 通过恶意路径访问文件系统
- Header Injection - 攻击者可注入恶意HTTP头
实际测试代码
// pages/api/protected.js
export default function handler(req, res) {
const { url } = req.query;
// 危险操作：直接使用用户输入
const response = await fetch(url);
res.json({ data: response.body });
}
防护方案
1. 输入验证和白名单
const ALLOWED_DOMAINS = ['api.example.com', 'api.github.com'];
function validateUrl(url) {
try {
const parsed = new URL(url);
return ALLOWED_DOMAINS.includes(parsed.hostname);
} catch (e) {
return false;
}
}
2. 使用Next.js中间件
// middleware.js
export function middleware(request) {
const url = request.nextUrl.pathname;
if (url.includes('..')) {
return new Response('Forbidden', { status: 403 });
}
}
性能对比数据
| 方案 | 渲染时间(ms) |
|---|---|
| 无防护 | 85ms |
| 基础防护 | 120ms |
| 完整防护 | 145ms |
实际测试中发现，完整防护方案虽增加了约65%的处理时间，但安全收益远大于性能损耗。建议在生产环境必须部署完整防护方案。
最终建议： SSR安全防护应该在项目初期就考虑，而不是后期补救。建议使用next-safe和helmet等中间件进行组合防护。
讨论