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

Руководства по безопасности

#Next.js#CVE#зависимости#Docker

Безопасный запуск Next.js: не отставать от опубликованных CVE

В Next.js страшнее всего оставить опубликованную CVE незакрытой — RCE с CVSS 10.0 многомесячной давности уже вызывала реальные взломы. Четыре столпа: судите по работающей версии, машинно мониторьте зависимости, быстро обновляйтесь и минимум привилегий — через операционную призму этого сайта.

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

Для тех, кто выкатывает приложения на Next.js (или похожих JS-фреймворках), особенно «собрал с помощью ИИ, эксплуатирую на ощупь». Выжато из реального инцидента (→ заброшенная CVSS 10.0).

Взгляд этого сайта: битва выигрывается не на «скорости»

Инди-разработчики обычно проигрывают в безопасности не от нехватки знаний, а от нехватки операционной непрерывности. Читать новости о CVE быстрее всех не имеет ценности (скорость оставьте вендорам и новостям). Работает система, которая не упустит релевантные вам CVE. Поэтому эта статья опирается на «систематизируй», а не «знай больше».

1. Судите по работающей версии

Измеряйте «на опасной ли я версии» по тому, что реально работает, а не по нижней границе манифеста — потому что число в манифесте и работающая версия часто расходятся.

✗ Считать по нижней границе package.json

"next": "^16.0.0" → «16.0.0 уязвима, значит и мы» — пересчитано как «8 уязвимых».

✓ Считать по работающей версии

npm ls next показывает разрешённую версию → автообновлённые безопасны, отстают лишь зафиксированные. Реально 2.

Нижняя граница package.json лжёт. Судите по работающей версии — и риск меняется (8 «уязвимых» стали 2).
# посмотреть реально разрешённые версии
npm ls next react react-dom
# внутри работающего контейнера
docker exec <container> npm ls next

Диапазоны с кареткой (^16.0.0) автообновляются при пересборке; зафиксированные зависимости отстают. Истина — эти числа.

2. Машинно мониторьте зависимости

Отслеживать CVE вручную невозможно, и пропуск становится инцидентом. Пусть следят машины.

Бесплатный мониторинг зависимостей

osv-scanner scan -L pnpm-lock.yaml

На GitHub включите Dependabot (Settings → Security). Вы будете получать PR только для CVE, совпадающих с вашими зависимостями.

Важна приоритизация. Позиция этого сайта: ранжируйте по «эксплуатируется ли (KEV)», умноженному на «насколько высок CVSS». Высокий CVSS у того, чем вы не пользуетесь, — малое воздействие; средний балл под активной эксплуатацией — высший приоритет, — именно эта приоритизация и есть настоящая работа.

3. Дисциплина обновлений: исправляйте корень, а не симптом

Когда появляется уязвимость, обновите фреймворк до исправленной версии, чтобы закрыть саму дыру.

Сокрытие симптома (недостаточно)

  • Блокировать только «подозрительно выглядящие» запросы на обратном прокси
  • Остановить списания/симптом и назвать «разобрались»
  • Оставить саму RCE живой

Корневое исправление (правильно)

  • Обновить фреймворк до исправленной версии
  • После обновления убедиться, что сигнатура исчезла из логов
  • Считать первую помощь и корневое исправление двумя разными задачами и делать обе

Частый провал

«Остановили списания/симптом» ≠ «разобрались». Первая помощь и закрытие уязвимости — разные задачи. Делайте обе.

4. Минимум привилегий, чтобы сжать радиус поражения

Сдержите ущерб, если вас всё же пробьют.

1

Запускайте от непривилегированного пользователя

Не запускайте USER контейнера как root. Взлом достаёт лишь «эту привилегию».
2

Привяжите БД/Redis только к внутренней сети

Никогда не публично. Сократите напрямую достижимую поверхность.
3

Разделяйте по сервисам

Разнесите сети и данные по сервисам, чтобы один взлом не каскадировал на всё.

Это решает, остановится ли взлом на «краже окружения внутри контейнера» или дойдёт до «захвата хоста».

Мы делаем это сами

Этот сайт мониторит свои зависимости на предмет CVE ровно так, как написано здесь, — чтобы инцидент, с которого всё началось (заброшенная публичная CVSS 10.0), больше никогда не был упущен человеком. Мы говорим «ранжируйте по приоритету (KEV + CVSS)», потому что именно так и работаем.

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

FAQ

QЧто важнее всего для безопасности Next.js?
A

Прежде чем не писать баги — это не оставлять опубликованные CVE во фреймворке или его зависимостях незакрытыми. Большинство тяжёлых взломов идут от заброшенных известных дыр, а не от новых атак.

QМогу ли я по package.json понять, уязвим ли я?
A

Нет. `^` (нижняя граница) в package.json не отражает реальность — диапазоны с символом каретки автообновляются при пересборке, зафиксированные зависимости отстают. Всегда судите по реально работающей версии.

QЧто сделать первым делом в одиночку?
A

Включите Dependabot (GitHub) или osv-scanner, чтобы машины следили за CVE в ваших зависимостях. Ручные обходы всегда что-то пропускают. Система, которая продолжает работать, бьёт больше знаний.