Введение
Экосистема Next.js в 2026 году стала стандартом для построения высоконагруженных веб-приложений. Согласно данным опроса State of JavaScript 2025, более 62% респондентов используют Next.js как основной фреймворк для серверного рендеринга и API-маршрутов. Однако с ростом популярности растёт и количество атак. По отчёту OWASP API Security Top 10 (2026) — последней актуальной версии документа, опубликованной в июне 2026 года, — более 73% протестированных API-приложений содержат хотя бы одну критическую уязвимость. В этой статье я разберу 10 наиболее частых проблем безопасности, которые мы находим при аудите Next.js-проектов в 2026 году. Каждый пункт сопровождается реальным примером, техническим объяснением и рекомендацией по исправлению.
1. Неправильная обработка CORS в API Routes
Одна из самых частых ошибок — глобальная настройка CORS с разрешением всех источников. В Next.js API Routes многие разработчики используют промежуточные слои (middleware), которые устанавливают заголовок Access-Control-Allow-Origin: *. Это делает API доступным для любого внешнего сайта, что позволяет злоумышленникам выполнять запросы от имени пользователя.
Пример:
// pages/api/user.js
export default async function handler(req, res) {
res.setHeader('Access-Control-Allow-Origin', '*');
res.status(200).json({ secret: 'user-data' });
}
Рекомендация:
Используйте библиотеку cors с точным списком разрешённых доменов:
import Cors from 'cors';
const cors = Cors({
methods: ['GET', 'POST'],
origin: ['https://mydomain.com'],
});
По данным исследования Snyk (2025), 34% Next.js-проектов с открытым исходным кодом содержат некорректные CORS-настройки.
2. Отсутствие валидации входных данных
Следующая по частоте проблема — передача в API-обработчик непроверенных данных. Злоумышленник может отправить JSON с вложенными объектами, содержащими SQL-инъекции или NoSQL-инъекции. В 2026 году библиотека zod остаётся самым популярным инструментом для валидации схем.
Пример уязвимости:
// pages/api/update-user.js
export default async function handler(req, res) {
const { name } = req.body;
await db.collection('users').updateOne({ _id: userId }, { $set: { name } });
// Если name содержит $gt — возможна инъекция
}
Решение:
Используйте zod для строгой валидации:
import { z } from 'zod';
const schema = z.object({
name: z.string().min(1).max(100),
});
const parsed = schema.parse(req.body);
3. Неправильное управление сессиями через JWT
JWT (JSON Web Tokens) — популярный механизм аутентификации, но многие разработчики хранят токены в localStorage без подписи или с коротким сроком действия. В 2026 году OWASP рекомендует использовать httpOnly куки с флагами Secure и SameSite.
Проблема:
Если JWT хранится в localStorage, XSS-атака позволяет украсть токен. По данным отчёта HackerOne (2026), 41% утечек данных в веб-приложениях связаны с кражей JWT.
Рекомендация:
Устанавливайте JWT в httpOnly cookie на стороне сервера:
export default async function handler(req, res) {
const token = generateJWT(user);
res.setHeader('Set-Cookie', `token=${token}; HttpOnly; Secure; SameSite=Strict; Path=/`);
res.status(200).json({ success: true });
}
4. Отсутствие rate limiting на API-маршрутах
Без ограничения частоты запросов злоумышленник может выполнить brute-force атаку на эндпоинты аутентификации. В Next.js 14+ встроенный middleware позволяет легко добавить лимиты.
Пример:
Используйте пакет express-rate-limit вместе с @vercel/edge или встроенный rate-limiter-flexible:
import { RateLimiterMemory } from 'rate-limiter-flexible';
const limiter = new RateLimiterMemory({
points: 5,
duration: 60,
});
Согласно анализу Cloudflare (2026), 28% всех атак на API — это перебор паролей.
5. Небезопасное логирование и раскрытие конфиденциальных данных
Часто разработчики логируют весь запрос, включая пароли и токены. В Next.js это особенно опасно, так как логи могут попасть в Sentry, Datadog или другие сервисы мониторинга.
Рекомендация:
Используйте библиотеку pino с фильтрацией полей:
const logger = pino({
redact: ['req.headers.authorization', 'req.body.password'],
});
6. Игнорирование Server-Side Request Forgery (SSRF) в API Routes
Next.js API Routes могут выполнять запросы к внутренним сервисам. Если пользователь может влиять на URL запроса, злоумышленник может получить доступ к внутренним ресурсам.
Пример:
const response = await fetch(req.body.url); // уязвимо
Решение:
Валидируйте URL с помощью библиотеки validator:
import validator from 'validator';
if (!validator.isURL(url, { protocols: ['https'], require_protocol: true })) {
return res.status(400).json({ error: 'Invalid URL' });
}
7. Неправильное использование getServerSideProps с внешними API
Функция getServerSideProps выполняется на сервере, но если она делает запрос к внешнему API без проверки, это может привести к утечке данных.
Проблема:
export async function getServerSideProps(context) {
const response = await fetch('https://internal-api.local/data', {
headers: { Authorization: `Bearer ${process.env.INTERNAL_TOKEN}` },
});
return { props: { data: await response.json() } };
}
Рекомендация:
Используйте переменные окружения и не передавайте в пропсы чувствительные данные.
8. Отсутствие Content Security Policy (CSP)
CSP-заголовки защищают от XSS-атак, но многие Next.js-приложения их не устанавливают. В 2026 году Google Chrome требует CSP для новых функций, таких как SharedArrayBuffer.
Пример настройки в middleware:
res.setHeader('Content-Security-Policy', "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'");
9. Зависимости с известными уязвимостями
Экосистема npm постоянно обновляется, но многие проекты используют устаревшие пакеты. По данным npm audit (2026), средний Next.js-проект содержит 12 уязвимостей средней и высокой степени.
Рекомендация:
Используйте npm audit и snyk test в CI/CD:
npm audit --audit-level=high
10. Неправильная обработка ошибок
Стандартные ошибки Next.js часто содержат стек-трейсы, которые раскрывают структуру приложения.
Пример:
try {
// код
} catch (error) {
res.status(500).json({ error: error.message });
}
Решение:
Логируйте ошибки и возвращайте общее сообщение:
logger.error(error);
res.status(500).json({ error: 'Internal server error' });
Заключение
Безопасность API в Next.js — это не разовое действие, а постоянный процесс. Каждый из 10 пунктов выше — это реальная угроза, которую мы находим при аудите проектов. Я рекомендую внедрить автоматическое сканирование с помощью инструментов вроде OWASP ZAP, а также регулярно обновлять зависимости. Помните: одна уязвимость может стоить репутации и данных пользователей. Начните с малого — проверьте CORS, валидацию и rate limiting уже сегодня.
Если вы хотите углубиться в тему, рекомендую ознакомиться с официальной документацией Next.js по безопасности и последней версией OWASP API Security Top 10 (2026).
Комментарии