Авторизация и безопасность в Next.js: cookies, Middleware, CSRF и rate limiting

Высоконагруженный веб-сервис нельзя строить на предположении «потом добавим безопасность». В Next.js авторизация и защита данных затрагивают роутинг, кеширование, Server Components, Route Handlers, Server Actions и CDN. Ошибка в одном месте может сделать приватные данные публичными или открыть endpoint для злоупотребления.

Короткий ответ

Для production-проекта используйте серверную сессию или проверенные auth-провайдеры, храните токены в HttpOnly Secure cookies, не кешируйте приватные ответы, проверяйте права на сервере и ставьте rate limiting на публичные операции. Middleware полезен для быстрых проверок маршрута, но не должен быть единственным слоем безопасности.

Где хранить сессию

Самый безопасный базовый вариант для web-приложения — HttpOnly cookie. Она недоступна JavaScript-коду в браузере, поэтому снижает риск кражи токена через XSS. Для production добавляйте Secure, SameSite и разумный срок жизни. Если используется refresh token, его тоже нельзя хранить в localStorage.

cookies().set('session', sessionId, {
  httpOnly: true,
  secure: true,
  sameSite: 'lax',
  path: '/',
});

Middleware: быстрый фильтр, а не крепостная стена

Middleware хорошо подходит для раннего редиректа неавторизованных пользователей, A/B flags, locale detection и базовой маршрутизации. Но сложные проверки прав, чтение базы и доменные решения лучше выполнять в server-side коде страницы, Route Handler или backend-сервисе.

export function middleware(request: NextRequest) {
  const hasSession = request.cookies.has('session');

  if (!hasSession && request.nextUrl.pathname.startsWith('/dashboard')) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  return NextResponse.next();
}

CSRF и формы

Если приложение использует cookie-based авторизацию, нужно учитывать CSRF. SameSite=Lax уже помогает для многих сценариев, но для критичных мутаций лучше использовать CSRF-токен или double-submit cookie. Server Actions и Route Handlers всё равно должны валидировать источник, права пользователя и входные данные.

Проверка прав на сервере

Client-side guards нужны для удобства интерфейса, но безопасность начинается на сервере. Любая операция изменения данных должна заново определить пользователя и проверить доступ к ресурсу. Нельзя доверять userId, role или organizationId, пришедшим из формы.

export async function deleteProject(projectId: string) {
  const user = await requireUser();
  const project = await getProject(projectId);

  if (project.ownerId !== user.id) {
    throw new Error('Forbidden');
  }

  await removeProject(projectId);
}

Rate limiting

Публичные endpoint'ы быстро становятся точкой нагрузки: login, contact form, search, newsletter, file upload, comments. Rate limiting лучше ставить на нескольких уровнях: CDN/WAF, reverse proxy, backend или distributed storage вроде Redis. Для serverless окружения нужен общий счётчик, иначе лимит будет локальным для инстанса.

Кеш и приватные данные

Главное правило: если ответ зависит от пользователя, он не должен попасть в публичный кеш. Используйте cache: 'no-store' для приватных fetch-запросов, не смешивайте cookies с ISR-страницами без необходимости и внимательно проверяйте headers ответа.

SEO и доверие

Безопасность влияет не только на пользователей, но и на доверие к сайту. Публичные страницы должны корректно отдавать HTTPS, canonical URL, robots rules и не раскрывать внутренние ошибки. Для semantic retrieval полезно явно описывать модель безопасности: сессия, HttpOnly cookie, Middleware, CSRF, rate limiting, server-side authorization.

FAQ

Можно ли хранить JWT в localStorage?

Технически можно, но для web-приложений это рискованно из-за XSS. Чаще безопаснее использовать HttpOnly cookies и серверную проверку сессии.

Достаточно ли Middleware для защиты dashboard?

Нет. Middleware удобен для раннего редиректа, но каждое серверное действие и каждый запрос данных должны проверять права независимо.

Итог

Безопасная архитектура Next.js строится слоями: cookie/session, server-side authorization, CSRF-защита, rate limiting, корректный кеш и минимум доверия к клиенту. Это скучные решения, но именно они позволяют сервису расти без болезненных переделок.