Если неопубликованный текст из системы управления контентом виден обычному посетителю Next.js-сайта, сначала ограничьте дальнейший показ закрытых материалов и зафиксируйте наблюдение. Затем проверьте, используются ли Draft Mode и кеширующие функции, которые возвращают разные данные для редактора и гостя. Обновление приложения и проверка уже сохранённых ответов — отдельные задачи: исчезновение симптома в одном браузере ещё не подтверждает исправление.
Кому это актуально
Материал для владельца сайта или руководителя контент-команды, которая согласует страницы перед публикацией. Draft Mode — режим предварительного просмотра: редактор видит подготовленный материал, пока посетителю должна оставаться доступна только опубликованная версия.
30 сентября 2026 года команда Next.js описала ошибку, при которой одновременно выполняющиеся запросы редактора и гостя могут получить общий результат ещё не завершённого вычисления для кеша. Для этого сценария указаны конкретные условия: включены Cache Components либо experimental.useCache, используется Draft Mode, а кешируемая функция возвращает содержимое, зависящее от режима просмотра.
Само наличие Next.js или кнопки «Предпросмотр» не доказывает уязвимость. Разработчику нужно сопоставить версию и конфигурацию рабочего приложения с актуальным описанием проблемы. Если этих механизмов в проекте нет, причину раскрытия текста следует искать отдельно: например, в правилах доступа к контенту.
Какие риски закрывает проверка
Главный риск — публикация раньше согласования: посетитель может увидеть черновой текст, условия ещё не запущенной акции или внутреннее примечание редактора. Это возможные последствия, а не утверждение о произошедшей утечке на конкретном сайте.
В официальном сообщении о безопасности описан и более длительный эффект. Если гостевой запрос участвует в предварительной генерации страницы, неопубликованный результат может сохраниться и отдаваться следующим посетителям до обновления этой страницы. Поэтому выход редактора из режима просмотра сам по себе не служит доказательством, что публичные ответы очищены.
Если закрытый текст уже появился снаружи, не воспроизводите проблему на настоящих черновиках. Зафиксируйте время и адрес без секретных параметров, ограничьте затронутый сценарий и передайте проверку ответственному разработчику.
Проверять нужно границу между редактором и гостем. Обычная задача «после публикации остался старый текст» имеет другую цель — свежесть уже разрешённых к показу данных. Здесь критерий строже: неопубликованное содержимое не должно попадать в гостевой ответ вообще.
Как провести безопасную первичную проверку
Соберите сведения без изменения рабочего сайта
Запросите у разработчика версию реально запущенной сборки, наличие Cache Components или experimental.useCache и перечень маршрутов предварительного просмотра. Версия на компьютере разработчика может отличаться от версии развёрнутого приложения.
Попросите также обозначить, какие функции читают черновики из системы управления контентом и могут ли они использоваться несколькими страницами. Не нужно выгружать базу, пересылать ключ доступа к CMS или копировать полные журналы запросов в обычную переписку.
Сравните роли на тестовом материале
Для проверки подходит изолированный тестовый контур с настройками, существенными для проблемного сценария. Создайте вымышленную публикацию с явно различимыми вариантами: «Открытый текст» и «Тестовый черновик». В ней не должно быть реальных условий сделки, персональных данных или материалов под запретом разглашения.
Редакторский и гостевой сеансы должны быть разделены. Гость открывает обычный публичный адрес без ссылки предварительного просмотра и её параметров. Ожидаемый результат прост: редактор видит тестовый черновик, гость — только открытый текст.
Такая ручная проверка помогает описать симптом, но может не обнаружить ошибку, зависящую от совпадения запросов по времени. Проверку одновременных обращений поручают разработчику на согласованном тестовом контуре; массово обновлять рабочую страницу с настоящим черновиком не следует.
Составьте короткую карточку наблюдения
Достаточно записать маршрут, время, роль пользователя, ожидаемую и фактическую тестовую метку, версию сборки и способ открытия страницы. Отдельно отметьте, повторялось ли расхождение после завершения редакторского просмотра.
Если в адресе есть секрет предварительного просмотра, замените его в отчёте пометкой «параметр удалён». Скриншот с тестовыми словами полезнее полного сетевого дампа, который может содержать данные сеанса.
Как принять исправление
До выпуска согласуйте с разработчиком план обновления и проверок. Основанием должны быть актуальное сообщение Next.js, применимость исправления к вашей ветке и результат испытания на тестовом контуре. Одного изменения номера зависимости в файле проекта недостаточно: нужна подтверждённая версия запущенного приложения.
Для приёмки используйте проверяемые условия:
- редактор получает тестовый черновик, а независимый гость — опубликованный вариант;
- согласованный тест одновременных запросов сохраняет разделение ролей;
- после редакторского просмотра гостевой ответ не содержит тестовую закрытую метку;
- проверены другие маршруты, использующие ту же функцию получения контента;
- после штатной публикации обновлённый текст становится доступен обычному посетителю;
- зафиксирован порядок проверки и обновления ранее сформированных страниц и внешних кешей, если они участвуют в выдаче.
Последний пункт требует отдельного решения. Исправление приложения предотвращает конкретный механизм ошибки, но нельзя без проверки объявлять безопасными все ответы, сохранённые раньше. Разработчик должен определить затронутые копии и порядок их удаления или повторной генерации с учётом нагрузки.
Если закрытое содержимое действительно выдавалось гостям, восстановление правильного ответа не устанавливает, кто успел его получить. Оценку фактического раскрытия ведут отдельно от приёмки технического исправления.
Что запросить у подрядчика
Хороший результат проверки — короткий отчёт с основаниями решения. В нём нужны версия сборки, применимые условия из сообщения о безопасности, карта пути «CMS — функция получения данных — страница — посетитель» и результаты сценариев для двух ролей.
Попросите разделить выводы на «подтверждено», «исключено проверкой» и «пока неизвестно». Например, отсутствие закрытой метки в одном ответе подтверждает только этот ответ, а не отсутствие ошибки во всех маршрутах и режимах.
В плане выпуска должны быть ответственный, способ ограничения проблемного просмотра, проверка сохранённых страниц и условия остановки работ. Возврат старой сборки, которая сохраняет известный риск раскрытия, не стоит считать достаточным планом восстановления.
Частые вопросы
Достаточно ли проверить сайт в приватном окне?
Это полезная проверка гостевого сценария, если в окне нет редакторской сессии. Но один запрос не охватывает одновременные обращения и ранее сформированные страницы, поэтому отрицательный результат ограничен этим наблюдением.
Поможет ли просто очистить кеш?
Очистка может убрать сохранённую копию. Она не доказывает устранение причины, по которой черновик оказался в публичном ответе; проверять нужно и механизм получения данных, и развёрнутое исправление.
Нужно ли отключать предварительный просмотр навсегда?
Такого общего требования нет. При подтверждённом раскрытии временное ограничение сценария помогает прекратить дальнейший показ, а постоянное решение выбирают после проверки версии, конфигурации и разделения редакторских и гостевых ответов.
Как это решает OpenStart
Если собственная команда умеет проверять конфигурацию Next.js, проводить испытания в отдельном контуре и принимать обновление по этим критериям, привлекать нового подрядчика необязательно. Владелец сайта может самостоятельно подготовить безопасную карточку наблюдения и согласовать ожидаемый результат.
Когда непонятно, где пересекаются данные CMS, серверный рендеринг и кеш, задача относится к поддержке и доработке React/Next.js-проекта. OpenStart работает с существующим кодом, интеграциями и серверным рендерингом, проверяя изменения в тестовом контуре. Объём диагностики определяют по устройству конкретного проекта.
Для первичной оценки достаточно публичного адреса и описания различий между редакторским и гостевым просмотром без закрытого текста, cookie и ключей доступа. Следующий шаг — уточнение сценария, рисков и объёма работ.
Основа разбора: сообщение Next.js «September 2026 Security Release» и описание ошибки попадания Draft Mode в обычные ответы от 30 сентября 2026 года; документация Next.js по draftMode.