Перейти к содержимому
>_ITDITDПлатформа веб-безопасности

По фреймворкам

#Next.js#framework#access control#dependency management

Безопасность Next.js — практическая референс-инструкция по хардненингу продакшна

Референс по хардненингу продакшна Next.js: приоритетный чек-лист плюс граница сервер/клиент и переменные окружения, CVE зависимостей, авторизация Server Actions, SSRF, заголовки/CSP и ограничение частоты, с чек-листом самопроверки. Защитно, без шагов атаки.

Опубликовано 2026-07-02 Обновлено 2026-07-02 7 мин чтения

Для: всех, кто ведёт приложение на Next.js (предполагается App Router). Здесь нет шагов атаки — это рабочий референс по хардненингу: приоритетный чек-лист, руководство по областям и самопроверка. Общую по фреймворкам картину смотрите на хабе безопасности по фреймворкам.

Приоритетный чек-лист хардненинга

Выполняйте эту таблицу сверху вниз. P0 — предпосылка, P1 — самый частый источник инцидентов, P2 — постоянная операционная гигиена.

P0 ── Предпосылка (сначала это)

Секреты только на сервере / мониторинг CVE зависимостей + быстрый патчинг / надёжная конфигурация продакшна

P1 ── Главный источник инцидентов

Авторизация Server Actions/Route Handlers + валидация ввода / SSRF на серверных запросах

P2 ── Операционная гигиена

Заголовки/CSP / аутентификация, сессия, куки / ограничение частоты

Укрепляйте от фундамента вверх: P0 (предпосылка) → P1 (главный источник инцидентов) → P2 (операционная гигиена).
ПриоритетМераКонкретика (Next.js)
P0Секреты только на сервереNEXT_PUBLIC_ только для безопасных для браузера значений; секреты только в Server Component/Action/Route Handler
P0CVE зависимостейМониторьте через npm audit/osv-scanner; судите по работающей версии, быстро патчите. Успевайте за RCE в ядре
P0Конфигурация продакшнаЗапускайте production-сборку; не раскрывайте внутренности (стек/окружение) при ошибках
P1Авторизация действийАутентификация + авторизация с областью владельца в каждом Server Action/Route Handler
P1Валидация вводаВалидируйте ввод по схеме (тип/диапазон/допустимое). Не доверяйте клиенту
P1Защита от SSRFОграничьте серверные запросы URL белым списком + блокируйте внутренние IP/метаданные. Ограничьте remote patterns изображений
P2Заголовки/CSPЗаголовки безопасности + HSTS в next.config. Рассмотрите CSP на основе nonce в App Router
P2Аутентификация/кукиКуки сессии Secure/HttpOnly/SameSite. Не оставляйте авторизацию только на middleware
P2Ограничение частотыОграничения на аутентификацию, Server Actions и Route Handlers

1. Граница сервер/клиент и переменные окружения (P0)

Крупнейший источник инцидентов в Next.js — секреты, которые должны были остаться на сервере, попадают в клиент.

  • Добавляйте префикс NEXT_PUBLIC_ только к безопасным для браузера значениям. Никогда — к ключам API или данным подключения (значения NEXT_PUBLIC_ запекаются в клиентский бандл при сборке и видны посетителям).
  • Читайте секреты только внутри серверных компонентов / Server Actions / Route Handlers и держите их вне props и ответов (сериализуемых значений).
  • Не допускайте, чтобы серверные модули импортировались клиентом (случайное включение может добавить секреты в бандл). См. файлы .env и секреты.

2. CVE зависимостей и ядро (P0)

  • Машинно мониторьте CVE зависимостей (npm) через npm audit или osv-scanner, судите по работающей версии и быстро патчите (решайте по тому, что реально установлено, а не по объявлению в package.json).
  • У ядра Next.js бывали серьёзные RCE, поэтому быстро успевайте за ними при публикации. Об операционной дисциплине см. как не отставать от CVE; о практике — плейбук реагирования на уязвимости.
  • Держите Node/Next на поддерживаемых версиях и не оставляйте EOL-версии на месте.

3. Server Actions / Route Handlers (авторизация + валидация, P1)

Это публичные серверные точки входа. Возможность вызвать не означает, что это разрешено.

Частое (опасное)

  • действия трактуются как «залогинен = разрешено»
  • опора только на аутентификацию в middleware, без проверки владельца
  • ввод передаётся в БД или внешние вызовы без валидации
  • значения от клиента (ID, флаги) принимаются как есть

Правильно

  • аутентификация плюс авторизация с областью владельца/прав в каждом действии/обработчике
  • не оставляйте это на middleware (авторизуйте близко к данным)
  • валидируйте ввод по схеме (тип/диапазон/допустимое)
  • перепроверяйте на сервере, чтобы подмена ID не сработала

См. что такое IDOR. Делайте проверку владельца на каждом пути чтения/обновления/удаления.

4. SSRF и серверные запросы (P1)

Серверное получение URL, заданных пользователем (прокси изображений, вебхуки, получение метаданных), — это вход для SSRF.

  • Ограничьте цели белым списком и при подключении блокируйте доступ к приватным IP и метаданным облака (169.254.169.254).
  • Держите remote patterns оптимизации изображений в минимуме (не допускайте получения произвольных хостов).
  • См. что такое SSRF. Наш сайт направляет исходящие запросы через SSRF-безопасный шлюз.

5. Инъекции и вывод

  • XSS: React экранирует вывод по умолчанию. Не передавайте пользовательский ввод в dangerouslySetInnerHTML (только после санитизации, если это действительно нужно). См. что такое XSS.
  • SQL/инъекции: привязывайте через ORM/плейсхолдеры; никогда не собирайте запросы конкатенацией строк (→ что такое SQL-инъекция).
  • Не передавайте внешний ввод в опасное вычисление вроде eval.

6. Заголовки безопасности и CSP (P2)

  • Задайте заголовки безопасности (X-Content-Type-Options и т.д.) и HSTS в next.config. Проверьте свой сайт через проверку заголовков безопасности.
  • В App Router рассмотрите CSP на основе nonce (избегайте огульного разрешения инлайн-скриптов). Учтите, что сосуществование с тегами аналитики/рекламы требует проектирования.

7. Аутентификация, сессия, куки (P2)

  • Задавайте Secure / HttpOnly / SameSite на куках сессии.
  • Не делегируйте авторизацию только аутентификации в middleware — middleware это дополнение; проверяйте фактическое решение в действии/обработчике/слое данных (некоторые пути могут обойти middleware).
  • При входе уместно перегенерируйте и завершайте сессии.

8. Ограничение частоты (P2)

  • Применяйте лимиты попыток/пропускной способности к аутентификации, Server Actions и Route Handlers, чтобы сдержать перебор, злоупотребление и DoS.

Проверка: действительно ли ваш Next.js укреплён?

Собрать — это ещё не конец; готово только тогда, когда вы проверили. Это защитные самопроверки против собственного сайта/окружения.

1

Секреты не утекли клиенту

В исходном коде страницы в браузере или в бандле убедитесь, что ключи API или секреты не включены и что вы не добавили секрету префикс NEXT_PUBLIC_.
2

Продакшн не раскрывает внутренности при ошибках

Спровоцируйте ошибку и убедитесь, что ни трассировка стека, ни переменные окружения не показываются наружу.
3

Авторизация действий держится

В тестовом окружении запросите ID ресурса другого пользователя и убедитесь, что Server Action/Route Handler отклоняет (чтение/обновление/удаление).
4

Заголовки, зависимости, SSRF

Проверьте свой сайт через проверку заголовков, убедитесь, что npm audit/osv чист и что исходящие запросы не могут достучаться до внутренних IP.

Взгляд нашего сайта: управляйте «границей и зависимостями», а не ядром

Наш сайт работает на Next.js, и центр тяжести — не эффектные настройки, а граница сервер/клиент и свежесть зависимостей. Секреты остаются на сервере, публичные точки входа (Server Actions/Route Handlers) всегда несут авторизацию и валидацию ввода, а зависимости проходят аудит CVE перед каждым деплоем. Наше собственное происхождение — это инцидент «незакрытая CVE, автоматически эксплуатированная», поэтому машинный мониторинг зависимостей — привычка высшего приоритета. Исходящие запросы URL идут через SSRF-безопасный шлюз, чтобы они не могли достучаться до внутренних IP или метаданных.

Читать дальше

FAQ

QЧто сделать в первую очередь, чтобы защитить Next.js?
A

Три пункта P0: (1) держите секреты только на сервере (префикс NEXT_PUBLIC_ добавляйте только к безопасным для браузера значениям, никогда — к ключам API или данным подключения); (2) машинно мониторьте CVE зависимостей, судите по работающей версии и быстро патчите (включая RCE в ядре); (3) укрепите конфигурацию продакшна (запускайте production-сборку; не раскрывайте внутренности при ошибках). Далее переходите к авторизации Server Actions / Route Handlers и валидации ввода, а также к защите от SSRF.

QКак безопасно работать с переменными окружения?
A

Правило — «секреты остаются на сервере». Добавляйте префикс NEXT_PUBLIC_ только к безопасным для браузера значениям; никогда — к ключам API или данным подключения (значения NEXT_PUBLIC_ запекаются в клиентский бандл при сборке и видны посетителям). Читайте секреты только внутри серверных компонентов / Server Actions / Route Handlers и проектируйте так, чтобы они никогда не проскользнули в props или ответы.

QНа что обращать внимание в Server Actions?
A

Server Actions и Route Handlers — это публичные серверные точки входа. Возможность вызвать не означает, что это разрешено. Поверх входа (аутентификации) пишите авторизацию, ограничивающую каждую операцию владельцем, и всегда проверяйте ввод (например, валидацией по схеме). Не полагайтесь только на аутентификацию в middleware — делайте проверку владельца и в самом действии/обработчике.

QКак подготовиться к SSRF?
A

Главный вход — серверное получение URL, заданных пользователем (прокси изображений, вебхуки, получение метаданных). Ограничьте цели белым списком и при подключении блокируйте доступ к приватным IP и метаданным облака (169.254.169.254). Держите remote patterns оптимизации изображений в минимуме. Подробности см. в глоссарии.

QКак управлять уязвимостями npm-зависимостей?
A

Машинно мониторьте известные CVE с помощью npm audit или osv-scanner, судите по работающей версии и быстро патчите (решайте по тому, что реально установлено, а не по объявлению в package.json). У ядра Next.js бывали серьёзные RCE, поэтому важно быстро успевать за ними. Также держите Node/Next на поддерживаемых версиях и не оставляйте EOL-версии на месте.