В каталоге Next.js картинки загружаются с сервера поставщика, и внешне всё работает. Для проверки безопасности этого недостаточно: нужно знать, кто задаёт адрес изображения и куда за ним обращается сервер приложения. Начните с перечня разрешённых источников, владельцев их доменов и фактического обработчика картинок — эти сведения позволяют поставить разработчику конкретную задачу без экспериментов на рабочем сайте.
Кому это актуально
Разбор адресован владельцу интернет-магазина на Next.js, у которого изображения приходят из внешнего каталога или медиахранилища. Он поможет решить, достаточно ли штатного обновления или сначала нужно разобраться с неизвестными источниками.
В сообщении Next.js от 30 сентября 2026 года описан риск SSRF при оптимизации внешних изображений. SSRF — ситуация, когда приложение можно заставить выполнить серверный запрос к нежелательному адресу. Уведомление связывает риск с управляемым злоумышленником адресом, который попал в разрешённый список.
Если images.remotePatterns не настроен, официальный advisory исключает приложение из этого конкретного сценария. Это не заключение о безопасности собственных обработчиков загрузки или сайта в целом. Проверять надо настройки работающей сборки, а не только файл на компьютере разработчика.
Какие риски закрывает проверка
Сервер приложения может иметь сетевой доступ, которого нет у обычного посетителя. Поэтому при SSRF под угрозой оказываются доступные ему внутренние ресурсы. Наличие внешних картинок само по себе не доказывает ни уязвимость, ни состоявшуюся утечку.
Есть и риск для продаж: поспешное удаление разрешённых источников может оставить каталог без фотографий. Цель проверки — ограничить нежелательные запросы и сохранить нужные изображения. Для этого полезно заранее описать, какие источники используются на самом деле и что должно происходить при их недоступности.
Как проверить внешние источники
Найти место, где сервер получает картинку
Попросите разработчика проследить один обычный товар: от поля изображения в каталоге до запроса за файлом. Зафиксируйте, используется ли встроенная оптимизация Next.js, сторонний сервис или собственный обработчик. Одинаковый внешний вид страницы не означает одинаковую схему загрузки.
Отдельно выясните, кто может менять исходную ссылку: сотрудник, поставщик через обмен, пользователь или программный интерфейс. Поле в базе данных не становится доверенным только потому, что оно уже сохранено.
Составить карточку каждого источника
Для каждого реально используемого источника достаточно короткой записи:
- где он нужен: карточка товара, список, поиск или корзина;
- кто добавляет и меняет адрес изображения;
- кому принадлежит домен и кто управляет его DNS — записями, связывающими имя с сетевым адресом;
- какой участок хранилища нужен магазину;
- что показывать, если изображение не удалось получить;
- какое основание есть для доверия этому источнику.
Например, в условном магазине фотографии основного каталога находятся в собственном хранилище, а часть поставщиков передаёт ссылки на свои серверы. Эти группы стоит проверить раздельно: разрешение одному хранилищу не подтверждает доверие ко всем поставщикам. Пример описывает способ разбора, а не результат проверки конкретного проекта.
Сопоставить список с настройками
Документация Next.js позволяет ограничивать remotePatterns по протоколу, имени хоста, порту, пути и параметрам запроса. Разработчик должен объяснить широкие шаблоны и пропущенные ограничения. Практический вопрос владельца: почему приложению нужен весь внешний домен, если магазин использует только свой раздел каталога?
Отдельное внимание — переходам на другой адрес при загрузке. В документации указано, что разрешённый источник может ответить перенаправлением, после которого remotePatterns повторно не проверяется. Поэтому совпадение начального адреса со списком не заменяет проверку конечного направления и поведения используемой версии.
Advisory рекомендует проверить доверие к управлению DNS разрешённых хостов. Совпадение названия домена с привычным поставщиком не отвечает на этот вопрос.
Безопасная первичная проверка — чтение конфигурации, кода и сведений о владельцах источников. Не отправляйте специально составленные запросы к внутренним адресам рабочего сервера. Проверку защитных сценариев проводит разработчик в изолированной среде с разрешёнными тестовыми ресурсами.
Как принять исправление
Для затронутого проекта требуется обновление по актуальному официальному уведомлению. Проверка источников помогает определить условия риска и объём работ, но не заменяет исправление зависимости. Не объединяйте эту задачу с заменой медиахранилища без отдельной причины.
Согласуйте проверяемый результат до изменения:
- Рабочая версия подтверждена. Есть связь между исправлением, собранным приложением и всеми экземплярами, обслуживающими посетителей.
- Нужные картинки сохранены. На тестовой среде проверены карточка товара, список, поиск и корзина с изображениями из каждой разрешённой группы.
- Лишний источник отклоняется. Проверка в изолированной среде подтверждает выбранные ограничения; одного успешного открытия обычной картинки недостаточно.
- Отказ поставщика предусмотрен. Страница остаётся пригодной для выбора товара и показывает согласованную замену изображения.
- Сетевые ограничения учтены. Специалист проверил, какие исходящие соединения нужны приложению. OWASP рекомендует ограничивать их и на уровне сети, чтобы уменьшать последствия SSRF.
При сбое выпуска нельзя считать возврат уязвимой сборки полноценным решением. Заранее согласуйте безопасный временный режим: например, использование подготовленных изображений при отключённом проблемном пути загрузки. Его применимость зависит от архитектуры магазина.
Что запросить у подрядчика
Итогом должна стать короткая запись с основанием решения: затронут ли проект, какие источники оставлены и почему, что изменено, как проверены ограничения и каталог. К ней нужны ответственный за разрешённые источники и правило пересмотра списка при подключении нового поставщика.
Если связь между адресом в каталоге и запросом сервера не установлена, честный результат первого этапа — перечень неизвестного и план его проверки. Формулировка «картинки открываются, значит всё безопасно» не подтверждает исправление.
Как это решает OpenStart
Собственная команда может выполнить проверку, если ей доступны код, сборка, настройки и тестовая среда. Внешний подрядчик полезен, когда магазин передан без документации, источники добавлялись годами или обработка изображений связана с несколькими интеграциями.
В рамках поддержки React- и Next.js-проектов OpenStart разбирает существующий код, зависимости и сборку, проверяет критичные сценарии и предлагает план изменений. Для описанной задачи разумный первый этап — установить путь загрузки изображений и согласовать границы исправления.
Для первичного обращения достаточно публичной ссылки и описания того, откуда поступают фотографии. После обращения уточняются ограничения, риски и первый этап работ; пароли, ключи и закрытые данные для такого описания не нужны.
Частые вопросы
HTTPS у поставщика решает проблему?
HTTPS защищает соединение, но не определяет, кому приложению разрешено отправлять запросы. Доверие к источнику, направление соединения и применимость исправления проверяются отдельно.
Можно временно разрешить все домены, чтобы вернуть картинки?
Такое изменение расширяет доступные источники и затрудняет контроль. Сначала выясните, какой разрешённый адрес перестал подходить под правило; восстанавливать конкретный необходимый путь безопаснее, чем снимать ограничения целиком.
Если используется собственный загрузчик, проверка не нужна?
Сначала надо выяснить, какой сервис фактически получает файл. Собственный загрузчик может передавать эту работу внешней системе, а может быть частью отдельной серверной логики. Неприменимость конкретного advisory Next.js не подтверждает безопасность этой логики.