Границы аутентификации: почему middleware и layout не защищают, и Data Access Layer, который защищает

Middleware — швейцар, а не сейф

Задайте себе вопрос: если бы кто-то мог не атаковать вашу проверку, а просто пропустить её целиком — что откроется? Этот вопрос не гипотетический: CVE-2025-29927 ответил на него для каждого приложения, чья единственная проверка жила в middleware.

Middleware выполняется до разрешения маршрута, на каждом подходящем запросе, и потому кажется естественным местом для аутентификации: один файл, все маршруты накрыты. Но посмотрите, что он умеет делать хорошо: он работает в ограниченном рантайме, где не стоит ходить в базу на каждом запросе, так что практичный паттерн — оптимистичная проверка: прочитать сессионный cookie, возможно, локально сверить подпись и средиректить неаутентифицированных на /login до любой работы рендеринга. Это по-настоящему ценно: быстро (доли миллисекунды, без IO), разлогиненные никогда не видят вспышку защищённого UI, и политика редиректов централизована. Чем это не должно быть никогда — единственной проверкой.

CVE-2025-29927 — каноническое доказательство, и его механизм стоит знать точно. Next.js использовал заголовок x-middleware-subrequest внутри — чтобы предотвратить бесконечную рекурсию: если middleware инициировал fetch, снова попадающий в middleware, заголовок говорил Next «уже было, пропусти». Провал границы доверия: внешние запросы с этим заголовком были неотличимы от внутренних, и атакующий, знающий ожидаемое значение (выводимое из пути файла middleware и повторённое до нужной глубины рекурсии), мог велеть фреймворку пропустить вашу аутентификацию целиком. Хостинг Vercel срезал заголовок на edge; self-hosted-деплои были открыты. Патч починил заголовок, но класс выжил: любую одиночную проверку у парадной двери можно обойти — контрабандой заголовков, ошибкой маршрутизации прокси, паттерном matcher, забывшим маршрут, или следующим CVE. Defense-in-depth здесь не фраза для комплаенса — это вывод, к которому инцидент принуждает архитектуру.

Layout не защищает своих детей

Второе соблазнительное место для проверки — layout.tsx: он оборачивает каждую страницу под собой, и проверка сессии в нём выглядит периметром. Это не периметр — по двум архитектурным причинам, не имеющим отношения к багам. Первая: layout не перерендеривается при клиентской навигации — частичный рендеринг сохраняет общие layout-ы, и навигация с /dashboard/a на /dashboard/b перерендеривает только сегмент страницы. Проверка в layout выполнилась один раз, при первой загрузке; если сессию с тех пор отозвали или пользователь вышел в другой вкладке, навигация внутри раздела вопрос больше не задаёт. Вторая: layout и страница рендерятся независимо. Это отдельные записи в RSC-payload, рендеримые в параллельных серверных проходах; layout не может передать пропсы странице, и — главное — запросы данных страницы не ждут вердикта проверки в layout. Защищённые данные выбираются из базы, пока layout ещё решает, редиректить ли.

Есть и более острая версия того же факта: клиент может запросить RSC-payload конкретного сегмента напрямую. Частичный пререндеринг и посегментные запросы означают, что единица доставки у фреймворка — сегмент, а не обёрнутое дерево, так что рассуждение «моя страница в безопасности, потому что что-то выше проверяет» опирается на гарантию вложенности, которой модель рендеринга не даёт. redirect() в layout — любезность для UX, которая обычно срабатывает; это не граница безопасности, которая срабатывает всегда. Доки Next.js по аутентификации говорят это одной строкой — проверяйте близко к источнику данных, не в layout-ах, — и команды проскальзывают мимо, потому что проверка в layout кажется работающей в каждом ручном тесте. Она отказывает ровно там, где никто не тестирует руками: отозванные сессии посреди навигации, прямые запросы сегментов, гонки параллельных рендеров.

Data Access Layer: проверка при каждом чтении

Когда вы видите кодовую базу, где проверки аутентификации разбросаны по layout-ам, страницам и middleware, вопрос не «верна ли каждая проверка?», а «может ли запрос добраться до запроса в базу, минуя все?» Ответ почти всегда «да» — и DAL исключает этот класс вопросов, делая проверку неотделимой от чтения.

Граница, переживающая всё перечисленное, — та, что прикреплена к самим данным. Data Access Layer (DAL) — это модуль, единственный модуль, через который идут запросы к защищённым данным, и каждая его функция начинается с проверки сессии. Ни один путь к данным не может пропустить проверку, потому что проверка и есть путь. cache() из React делает это доступным по цене: verifySession мемоизируется на запрос, и десять вызовов DAL в одном дереве рендера стоят один поиск сессии, а не десять.

// app/lib/dal.ts
import 'server-only';
import { cache } from 'react';
import { cookies } from 'next/headers';
import { redirect, notFound } from 'next/navigation';
import { kv } from '~/lib/kv';
import { db } from '~/lib/db';

export const verifySession = cache(async () => {
  const token = (await cookies()).get('__Host-session')?.value;
  const session = token ? await kv.get(`session:${token}`) : null;
  if (!session) redirect('/login');   // мемоизировано: 10 вызовов за рендер = 1 поиск
  return session;
});

export async function getInvoice(id: string) {
  const session = await verifySession();        // на КАЖДОМ чтении — это и есть граница
  const invoice = await db.invoice.findUnique({ where: { id } });
  if (invoice?.ownerId !== session.userId) notFound(); // по-экземплярная авторизация, не только аутентификация
  return { id: invoice.id, total: invoice.total };     // DTO: возвращаем поля, не строки
}

Заметьте вторую проверку: ownerId !== session.userId. Аутентификация («кто ты») в начале функции, авторизация («можно ли тебе видеть эту строку») перед возвратом — обе принадлежат DAL, потому что обе суть свойства доступа к данным, а не маршрута. DTO-возврат — часть той же дисциплины: верните поля, нужные UI, и никогда — сырую строку, чтобы будущий клиентский компонент, получивший этот объект, не утёк колонками, которые никто не собирался отгружать. Слоистый итог: middleware даёт быстрые оптимистичные редиректы (UX), страницы и layout-ы рендерят что хотят (презентация), а DAL — единственное место, где утверждение безопасности действительно навязывается: место, куда не дотянутся ни обход middleware, ни забытая запись matcher, ни гонка layout-а, потому что запросу всё равно придётся пройти через verifySession, чтобы коснуться строки.