Новая парадигма требует новых подходов
Мир frontend-разработки за последние несколько лет изменился коренным образом. Если еще пять лет назад стандартом де-факто были одностраничные приложения (SPA), где вся логика выполнялась в браузере, а сервер был просто REST API, то сегодня мы наблюдаем массовый переход к гибридным архитектурам. Next.js с его Server Components и Server Actions стал не просто популярным фреймворком, а промышленным стандартом для enterprise-приложений.
Этот переход принес с собой множество преимуществ: улучшенную производительность, лучший SEO, упрощенную разработку. Однако он же изменил и модель угроз, с которыми сталкиваются разработчики. Привычные методы защиты, основанные на JWT в заголовках и CORS-политиках, больше не обеспечивают полную безопасность. Серверная логика теперь исполняется в непосредственной близости от клиента, а граница между фронтендом и бэкендом стала размытой (для некоторых сценариев).
По данным исследований Snyk и других security-вендоров, 39% облачных средств содержали уязвимые версии React и Next.js в 2024-2025 годах. Это не просто статистика. Это реальные приложения, обрабатывающие данные пользователей, платежную информацию и конфиденциальные бизнес-данные. Уязвимость CVE-2025-55182, получившая максимальный рейтинг CVSS 10.0, показала, насколько критичными могут быть последствия недостаточного внимания к безопасности в современных frontend-приложениях.
React Server Components (RSC) стали новым стандартом, но вместе с ними пришли новые векторы атак. Server Actions, предоставляющие удобный способ вызова серверной логики прямо из компонентов, фактически являются публичными HTTP-эндпоинтами. При неправильной конфигурации они могут стать лазейкой для злоумышленников. Традиционный подход security through obscurity здесь не работает: скрытие эндпоинтов не защитит от целенаправленного перебора.
В этой статье мы рассмотрим архитектурные подходы к обеспечению безопасности в Next.js-приложениях. Не поверхностные рекомендации вроде «используйте HTTPS», а практические паттерны, которые можно применить уже сегодня. Мы разберем механизмы защиты на каждом уровне: от валидации входных данных до инфраструктурных мер.
Server Actions как вектор атаки
Server Actions — одна из самых заметных возможностей современного Next.js. Они позволяют писать серверную логику прямо в компонентах, вызывать ее из форм и обработчиков событий, не создавая явных API-эндпоинтов. На первый взгляд это выглядит как магия: пишем функцию с директивой use server, импортируем ее на клиенте, и все работает.
Но за этой удобством скрывается важный архитектурный момент. Каждая Server Action — это публичный HTTP POST-эндпоинт. Next.js автоматически создает маршрут для вызова этой функции, и этот маршрут доступен извне. Даже если функция не экспортируется явно из page.tsx, она все равно становится частью публичного API вашего приложения.
Это создает первую серьезную проблему: обход middleware. Традиционно разработчики используют middleware Next.js для защиты маршрутов — проверки аутентификации, прав доступа, rate limiting. Но Server Actions вызываются через специальные внутренние маршруты, которые могут не попадать под действие стандартного middleware. А значит проверка сессии в middleware не гарантирует защиту Server Action.
Вторая проблема — неявная публикация бизнес-логики. Когда мы пишем Server Action, легко забыть, что эта функция будет доступна для прямого вызова. Разработчик может предполагать, что функция будет вызываться только из определенной формы с определенными ограничениями. Но злоумышленник может изучить JavaScript-бандл клиента, найти имя и сигнатуру Server Action и вызвать ее напрямую с произвольными аргументами.
Рассмотрим небезопасный пример:
// app/actions/user.ts
"use server";
export async function updateUser(data: any) {
await db.user.update({
where: { id: data.id },
data: {
name: data.name,
email: data.email,
role: data.role,
},
});
}На первый взгляд код выглядит рабочим. Но здесь сразу несколько проблем:
Нет валидации входных данных — параметр data имеет тип any.
Нет проверки аутентификации — кто угодно может вызвать эту функцию.
Нет проверки авторизации — пользователь может обновить любой профиль, включая чужой.
Отсутствует ограничение на изменяемые поля — поле role может быть изменено обычным пользователем.
Теперь посмотрим на безопасную реализацию:
// app/actions/user.ts
"use server";
import { z } from "zod";
import { getSession } from "@/lib/auth";
import { canUpdateUser, canUpdateUserRole } from "@/lib/permissions";
const updateUserSchema = z.object({
id: z.string().uuid(),
name: z.string().min(1).max(100).optional(),
email: z.string().email().optional(),
});
export async function updateUser(rawData: unknown) {
const session = await getSession();
if (!session) {
throw new Error("Unauthorized");
}
const data = updateUserSchema.parse(rawData);
if (!canUpdateUser(session.userId, data.id)) {
throw new Error("Forbidden");
}
const user = await db.user.update({
where: { id: data.id },
data: {
name: data.name,
email: data.email,
},
select: {
id: true,
name: true,
email: true,
role: true,
},
});
return user;
}Что изменилось в безопасной версии:
Добавлена схема валидации с помощью Zod — только ожидаемые поля, с правильными типами и ограничениями.
Явная проверка сессии перед выполнением любой логики.
Проверка прав доступа — функция canUpdateUser определяет, может ли текущий пользователь редактировать указанный профиль.
Ограничение изменяемых полей — role исключен из схемы обновления.
Явное указание возвращаемых полей — предотвращение случайной утечки данных.
Этот паттерн можно назвать для frontend-разработчиков стандартной серверной разработкой эндпоинтов API. Каждая Server Action должна быть самодостаточной с точки зрения безопасности: не полагаться на то, что ее вызовут из «правильного» места, а явно проверять все входные данные и контекст выполнения.
Zod и TypeScript — Defense in Depth
TypeScript стал стандартом современной frontend-разработки. Он помогает отлавливать ошибки на этапе компиляции, обеспечивает автодополнение в IDE и делает код более поддерживаемым. Однако при работе с Server Actions одного TypeScript недостаточно.
TypeScript работает только на этапе компиляции. После сборки в продакшене все типы стираются — JavaScript не имеет информации о типах во время выполнения. Это означает, что если злоумышленник отправит в Server Action данные неправильного типа, TypeScript не сможет это предотвратить.
Здесь на помощь приходит подход Defense in Depth (защита в глубину). Мы используем TypeScript для проверки на этапе разработки, а runtime-валидацию — для проверки на этапе выполнения. Это создает два независимых слоя защиты.
Zod — одна из самых популярных библиотек для схемной валидации в TypeScript-экосистеме. Она позволяет определять схемы данных, которые автоматически выводят типы TypeScript. Это означает, что у нас есть единый источник истины для валидации и типизации.
import { z } from "zod";
// Определяем схему
const userSchema = z.object({
id: z.string().uuid(),
name: z.string().min(1).max(100),
email: z.string().email(),
age: z.number().int().min(0).max(150).optional(),
role: z.enum(["user", "admin", "moderator"]),
});
// Выводим тип из схемы
type User = z.infer<typeof userSchema>;
// Используем в Server Action
export async function createUser(rawData: unknown) {
const data = userSchema.parse(rawData);
// Теперь data имеет тип User и гарантированно прошла валидацию
return db.user.create({ data });
}Преимущества такого подхода очевидны:
Runtime-валидация гарантирует, что данные соответствуют ожиданиям.
Автоматический вывод типов исключает рассинхронизацию между схемой и типами.
Декларативная запись схемы делает код читаемым.
Встроенные сообщения об ошибках помогают отладке.
Для Server Actions существует специализированная библиотека next-safe-action. Она предоставляет type-safe обертку над Server Actions с встроенной валидацией:
import { createSafeActionClient } from "next-safe-action";
import { z } from "zod";
const actionClient = createSafeActionClient();
export const updateUserAction = actionClient
.schema(
z.object({
id: z.string().uuid(),
name: z.string().min(1),
}),
)
.action(async ({ parsedInput }) => {
// parsedInput уже провалидирован и типизирован
return db.user.update({
where: { id: parsedInput.id },
data: { name: parsedInput.name },
});
});next-safe-action автоматически обрабатывает ошибки валидации, возвращает типизированные ответы и интегрируется с системой типов Next.js. Это позволяет фокусироваться на бизнес-логике, не беспокоясь о рутине валидации.
Важно понимать, что валидация входных данных — это только первый уровень защиты. Даже если данные прошли проверку схемы, это не означает, что они безопасны с точки зрения бизнес-логики. Например, строка, соответствующая формату email, все еще может принадлежать другому пользователю или быть заблокированной. Поэтому после схемной валидации всегда нужны бизнес-проверки.
Предотвращение утечек конфиденциальных данных
Одна из самых тонких проблем в архитектуре с Server Components — случайная утечка конфиденциальных данных на клиент. В традиционных SPA разделение было четким: сервер отдает только то, что нужно клиенту. В Next.js с Server Components граница размыта, и легко ошибочно передать в клиентский компонент данные, которые должны остаться на сервере.
Текущий подход (React 18 и Next.js 14)
В текущих версиях для предотвращения утечек используется комбинация паттернов:
1. Разделение клиентских и серверных компонентов. Компоненты с use client получают только те данные, которые явно переданы через props. Server Components могут обращаться к базе данных напрямую, но их результат рендеринга отправляется клиенту в виде HTML или сериализованных данных.
2. Server-only пакеты. Next.js предоставляет возможность пометить модуль как сервер-only, что предотвратит его импорт в клиентские компоненты:
// lib/database.ts
import "server-only";
export async function getUserWithSecrets(id: string) {
return db.user.findUnique({
where: { id },
include: { apiKeys: true, internalNotes: true },
});
}Если попытаться импортировать эту функцию в клиентский компонент, сборка завершится с ошибкой.
3. DTO (Data Transfer Objects). Явное ограничение полей, передаваемых в клиент:
async function getUserPublicProfile(id: string) {
const user = await db.user.findUnique({ where: { id } });
// Возвращаем только публичные поля
return {
id: user.id,
name: user.name,
avatar: user.avatar,
// apiKey, email, phone - исключены намеренно
};
}Ограничение этого подхода заключается в том, что он полагается на дисциплину разработчика. Нет runtime-проверки, которая бы предотвратила случайную передачу sensitive-данных.
Будущее: React 19 и Taint API
React 19 вводит экспериментальный Taint API, который добавляет runtime-защиту от утечек конфиденциальных данных. Этот механизм позволяет «маркировать» определенные значения как конфиденциальные, и React будет выбрасывать ошибку при попытке передать их в клиентский компонент.
import {
experimental_taintUniqueValue,
experimental_taintObjectReference,
} from "react";
// Маркируем уникальное значение (пароль, API-ключ)
experimental_taintUniqueValue(
"Нельзя передавать пароль на клиент",
process.env.ADMIN_PASSWORD,
);
// Маркируем объект целиком
const sensitiveConfig = {
apiKey: process.env.API_KEY,
dbUrl: process.env.DATABASE_URL,
};
experimental_taintObjectReference(
"Конфигурация содержит секреты",
sensitiveConfig,
);
// При попытке передать такие данные в клиентский компонент
// React выбросит ошибку во время рендерингаЭто значительно повышает уровень защиты: даже если разработчик случайно попытается передать секрет в клиент, приложение не сломает production, а сообщит об ошибке на этапе разработки или во время выполнения.
Уроки CVE-2025-55182
Декабрь 2025 года стал напоминанием о важности timely security updates. Уязвимость CVE-2025-55182 затронула React Server Components и получила максимальный рейтинг критичности CVSS 10.0. Это была RCE-уязвимость (Remote Code Execution), позволявшая злоумышленнику выполнять произвольный код на сервере.
Уязвимыми оказались версии React 19.0.0-19.2.0 и Next.js 15/16 до соответствующих патчей. Исправленные версии: React 19.2.1+, Next.js 15.1.9+, 16.2.2+
Что важно понимать: эта уязвимость не была следствием неправильной конфигурации со стороны разработчиков. Она была в самом фреймворке. Но последствия для приложений, которые вовремя не обновились, могли быть катастрофическими.
Практические рекомендации по безопасному использованию React 19:
Использовать только исправленные версии (19.2.1+).
Внедрить Taint API для критичных данных.
Настроить автоматические уведомления о новых CVE для зависимостей.
Иметь план экстренного обновления на случай критических уязвимостей.
Рекомендации по миграции
Если вы планируете переход на React 19 и Next.js 15+, то важно:
Провести аудит всех мест передачи данных между Server и Client Components.
Идентифицировать все конфиденциальные данные, которые могут случайно попасть на клиент.
Внедрить DTO-паттерн везде, где возможна утечка.
Использовать Taint API для дополнительной защиты.
Обновить политику мониторинга security-альертов.
RBAC и контроль доступа на сервере
Проблема контроля доступа в Next.js усугубляется тем, что middleware, работающий на Edge, не имеет доступа ко всем данным сессии. Разработчики часто полагаются только на middleware для защиты маршрутов, но это недостаточно для серьезных приложений.
Проблема ID Enumeration
Классическая уязвимость в веб-приложениях — ID Enumeration (перебор идентификаторов). Если приложение использует последовательные числовые ID и не проверяет права доступа, злоумышленник может перебирать ID и получать доступ к чужим данным:
// Уязвимый код
export async function getDocument(id: string) {
// Нет проверки, имеет ли право текущий пользователь
// получать этот документ
return db.document.findUnique({ where: { id } });
}При такой реализации любой аутентифицированный пользователь может получить любой документ, просто перебирая ID.
Почему middleware-only недостаточно
Middleware Next.js выполняется на Edge перед обработкой запроса. Он хорошо подходит для:
Проверки наличия сессии.
Редиректов неаутентифицированных пользователей.
Простых проверок на уровне маршрута.
Но у него есть ограничения:
Нет доступа к полной информации о пользователе из базы данных.
Нет контекста конкретного ресурса (какой именно документ запрашивается).
Невозможно проверить сложные бизнес-правила доступа.
Паттерн Proxy-слой авторизации
Решением является реализация авторизации непосредственно в Server Actions и Server Components. Каждая функция, работающая с данными, должна сама проверять права доступа.
// lib/authorization.ts
import { getSession } from "./auth";
export async function authorizeDocumentAccess(documentId: string) {
const session = await getSession();
if (!session) {
throw new Error("Unauthorized");
}
const document = await db.document.findUnique({
where: { id: documentId },
include: { members: true },
});
if (!document) {
throw new Error("Not found");
}
const hasAccess =
document.ownerId === session.userId ||
document.members.some((m) => m.userId === session.userId);
if (!hasAccess) {
throw new Error("Forbidden");
}
return document;
}
// app/actions/documents.ts
export async function updateDocument(
documentId: string,
data: UpdateDocumentData,
) {
// Авторизация проверяется внутри действия
const document = await authorizeDocumentAccess(documentId);
// Дополнительная проверка прав на редактирование
if (document.ownerId !== (await getSession())?.userId) {
throw new Error("Only owner can edit");
}
return db.document.update({
where: { id: documentId },
data,
});
}Этот паттерн можно представить как архитектуру:
Client Request
|
Server Action / Server Component
|
Auth Check (сессия)
|
Authorization Layer (права на ресурс)
|
Business LogicКаждый уровень отвечает за свой аспект безопасности:
Auth Check подтверждает, что запрос исходит от аутентифицированного пользователя.
Authorization Layer проверяет, имеет ли этот пользователь право работать с конкретным ресурсом.
Business Logic выполняет операцию, зная, что все проверки пройдены.
Ролевая модель доступа (RBAC)
Для сложных приложений полезна ролевая модель. Роли определяют набор разрешений, а пользователи получают одну или несколько ролей:
// lib/rbac.ts
const permissions = {
document: {
read: ["user", "admin", "viewer"],
create: ["user", "admin"],
update: ["admin", "owner"],
delete: ["admin"],
},
} as const;
export function hasPermission(
userRole: string,
resource: keyof typeof permissions,
action: string,
): boolean {
const allowedRoles = permissions[resource][action] || [];
return allowedRoles.includes(userRole);
}
// Использование в Server Action
export async function deleteDocument(documentId: string) {
const session = await getSession();
if (!session || !hasPermission(session.role, "document", "delete")) {
throw new Error("Forbidden");
}
// ... выполнение удаления
}Инфраструктурные меры защиты
Помимо архитектурных паттернов кода, важны инфраструктурные меры защиты. Next.js предоставляет встроенные механизмы для защиты от распространенных атак.
CSRF-защита
Cross-Site Request Forgery (CSRF) — атака, при которой злоумышленник заставляет браузер пользователя выполнить нежелательное действие на сайте, где пользователь аутентифицирован.
Next.js защищает от CSRF «из коробки» для Server Actions:
Проверка Origin. Server Actions проверяют заголовок Origin, чтобы убедиться, что запрос исходит с того же домена.
SameSite Cookies. При правильной настройке cookies с флагом SameSite=Strict или SameSite=Lax браузер не отправит их при cross-origin запросах.
// middleware.ts
import { NextResponse } from "next/server";
export function middleware(request: NextRequest) {
const response = NextResponse.next();
// Дополнительные security-заголовки
response.headers.set("X-Frame-Options", "DENY");
response.headers.set("X-Content-Type-Options", "nosniff");
response.headers.set("Referrer-Policy", "strict-origin-when-cross-origin");
return response;
}Rate Limiting на Edge
Защита от DoS-атак и перебора паролей реализуется через rate limiting. Next.js позволяет реализовать его на уровне Edge-функций для минимальной задержки:
// middleware.ts
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
const ratelimit = new Ratelimit({
redis: Redis.fromEnv(),
limiter: Ratelimit.slidingWindow(10, "1 m"),
});
export async function middleware(request: NextRequest) {
const ip = request.ip ?? "127.0.0.1";
const { success } = await ratelimit.limit(ip);
if (!success) {
return new NextResponse("Too many requests", { status: 429 });
}
return NextResponse.next();
}
export const config = {
matcher: ["/api/:path*", "/app/actions/:path*"],
};Для Server Actions можно реализовать rate limiting на уровне отдельных функций:
import { rateLimit } from "@/lib/rate-limit";
export async function sensitiveAction(data: unknown) {
// Rate limit по userId или IP
await rateLimit({
key: "sensitive-action",
limit: 5,
window: 3600, // 1 час
});
// ... основная логика
}Content Security Policy
Content Security Policy (CSP) — заголовок, который контролирует, какие ресурсы может загружать страница. Это защищает от XSS-атак и инъекций стороннего кода.
В Next.js CSP можно настроить через middleware:
// middleware.ts
export function middleware(request: NextRequest) {
const nonce = Buffer.from(crypto.randomUUID()).toString("base64");
const cspHeader = `
default-src 'self';
script-src 'self' 'nonce-${nonce}' 'strict-dynamic';
style-src 'self' 'nonce-${nonce}';
img-src 'self' blob: data:;
font-src 'self';
object-src 'none';
base-uri 'self';
form-action 'self';
frame-ancestors 'none';
upgrade-insecure-requests;
`
.replace(/\s{2,}/g, " ")
.trim();
const response = NextResponse.next();
response.headers.set("Content-Security-Policy", cspHeader);
response.headers.set("x-nonce", nonce);
return response;
}Для inline-скриптов в Server Components используется nonce:
import { headers } from 'next/headers'
export default function Page() {
const nonce = headers().get('x-nonce')
return (
<script nonce={nonce}>
{'console.log("Trusted inline script")'}
</script>
)
}Заключение
Безопасность в современном фронтенде требует переосмысления привычных подходов. Переход от SPA к гибридной архитектуре Next.js изменил не только способ разработки, но и модель угроз. Server Actions, React Server Components и новые API требуют осознанного подхода к защите.
Подведем итог:
Server Actions являются публичными HTTP-эндпоинтами и требуют явной валидации входных данных и проверки авторизации внутри каждой функции.
TypeScript защищает только на этапе компиляции. Для runtime-защиты необходима схемная валидация с помощью Zod или аналогичных библиотек, создающих подход Defense in Depth.
React 19 вводит Taint API для runtime-защиты от утечек конфиденциальных данных. Это дополнение к существующим паттернам server-only модулей и DTO.
CVE-2025-55182 продемонстрировала критическую важность timely security updates. Использовать React 19.2.1+ и Next.js 15.1.9+ обязательно для безопасности.
Middleware-only защита недостаточна. Каждая Server Action должна самостоятельно проверять права доступа к конкретным ресурсам через паттерн Proxy-слоя авторизации.
Бизнес-эффект от внедрения этих практик измеряется не только в предотвращении инцидентов, но и в репутационных рисках. Для enterprise-приложений, работающих с чувствительными данными, безопасность является не опциональной фичей, а фундаментальным требованием.
Что дальше
В первую очередь, рекомендуется провести аудит безопасности вашего Next.js-приложения. Проверьте Server Actions на наличие валидации данных и авторизации, убедитесь в отсутствии утечек sensitive-данных в клиентские компоненты, обновите зависимости до исправленных версий (React 19.2.1+, Next.js 15.1.9+).
Поделитесь в комментариях, какие паттерны безопасности используете вы в своих проектах? Какие инструменты автоматизации security-проверок считаете наиболее эффективными?
Подписывайся на наши соцсети и блог, где мы публикуем другие полезные материалы, в том числе и для frontend-разработчиков: