РУКОВОДСТВО 06 · ВЕБ-ПРИЛОЖЕНИЯ И API
Безопасность Next.js: проверка API Server Actions и секретов
В Next.js вход на страницу не определяет права всех серверных операций. Проследите путь от запроса до объекта и ответа клиенту: кто вызывает действие, какой projectId выбран и какие поля возвращаются. Проверьте другую личность и запрос без входа. Руководство относится к App Router; примеры необходимо сверять с версией развёрнутой сборки.
Проверить Next.js-приложениеПонадобятся вход, подтверждение владения и согласие. Для авторизованных сценариев, мониторинга и CI нужен Pro или Business.
Содержание
Краткий ответ и условия проверки
Проверяйте права в каждой серверной точке входа. Скрытая кнопка или Server Action не заменяет проверку сессии и владельца объекта.
Staging-сборка, две тестовые сессии и приватный маршрут или action с известным владельцем.
| Проверка | Ожидаемое доказательство |
|---|---|
| Действие | Вызовите серверную операцию напрямую от другого пользователя, затем проверьте другую сессию на повторное использование приватного ответа. |
| Положительный и отрицательный контроль | Уязвимый пример даёт доказательство, исправленный — нет. Успешный контрольный запрос подтверждает доступность цели. |
| Блокировка или недостающие данные | Отметьте проверку как пропущенную или незавершённую с причиной. Отсутствие аккаунта, ответ WAF и таймаут не означают отсутствие проблем. |
| После исправления | Повторите проверку той же цели, аккаунта и объекта. Сохраните исходное доказательство и новый результат; покрытие ограничено выполненными сценариями. |
Продолжить: Посмотреть пример отчёта
Продолжить: Покрытие и необходимые данные
Где проходит граница доверия
Server Components выполняют серверную работу, Client Components получают предназначенные браузеру данные, Server Actions и Route Handlers принимают внешние обращения. Размещение кода на сервере не делает выбранный объект разрешённым. В нашем примере две организации и один документ каждой; проверяется право на объект, а не возможность увидеть страницу. Scantelio проверяет доступное поведение подготовленных сценариев, не читает статически все Server Actions вашего репозитория.
Права внутри Server Actions и маршрутов
Для изменения проекта получите действующую сессию и загрузите выбранный объект. Затем проверьте право редактирования в его организации. projectId из формы — входные данные, а не подтверждение полномочий. Повторите запрос без входа, от владельца и от другой организации. Проверка в middleware или proxy может быть полезным первым барьером, но решение по конкретной операции должно оставаться рядом с доступом к данным.
const actor = await requireSession();
const document = await db.document.findUnique({ where: { id } });
if (!document || document.ownerId !== actor.id) throw new Error("Forbidden");
return { id: document.id, title: document.title }; // без внутренних полейПервичные источники: Next.js: безопасность данных · Next.js: переменные окружения
Продолжить: Утечка .env .git или API-ключа: как закрыть доступ и проверить исправление
Какие данные попадают в браузер
Не передавайте в клиентский компонент целиком запись пользователя или проекта из базы. Сформируйте DTO только с нужными полями, например id и displayName. Поле canEdit помогает нарисовать интерфейс, но не заменяет повторную серверную проверку при сохранении. В сетевом ответе не должно быть внутренних токенов, паролей или лишних данных другой организации. Проверяйте фактическую сериализацию, а не только видимые подписи на странице.
Проверить Next.js-приложениеNEXT_PUBLIC и переменные окружения
NEXT_PUBLIC обозначает данные, предназначенные для браузерной сборки. Такой префикс не скрывает значение. В примере NEXT_PUBLIC_SUPPORT_URL — публичная ссылка, BILLING_SECRET — серверная настройка; значения вымышленные. Если секрет попал в клиентский артефакт, уберите причину публикации, отзовите полномочия и выпустите исправленную сборку. Одной смены переменной на сервере может быть недостаточно для уже опубликованных файлов.
| Данные | Куда попадают | Правило |
|---|---|---|
| NEXT_PUBLIC_* | Клиентский build | Только публичные значения |
| Серверный секрет | Серверное окружение | Не включать в DTO, логи и HTML |
| Результат Server Action | Может попасть в браузер | Вернуть минимальный разрешённый DTO |
Первичные источники: Next.js: безопасность данных · Next.js: переменные окружения
Продолжить: IDOR и BOLA: как проверить доступ к чужим данным в своём API
Как проверить приватный кэш
Проверьте один приватный адрес на собственном стенде. На результат влияют версия Next.js, используемые API и настройки прокси.
Кэш страницы между двумя пользователями
Откройте ответ под A, затем запросите тот же URL под B и без входа. У A и B должны быть разные тестовые маркеры. Повторите в обратном порядке: так обнаружится случай, когда в кэш попал ответ первого пользователя.
Прямой ответ и ответ через CDN
Если стенд допускает оба пути, сравните содержимое и заголовки кэширования для одной и той же последовательности. Маркер A в ответе для B важнее значения заголовка: он показывает, какие данные действительно получил второй пользователь.
Версия фреймворка и зависимости
Сохраните точную версию Next.js и других библиотек вместе с идентификатором опубликованной сборки. Баннер или заголовок, похожий на Next.js, не доказывает применимость конкретной CVE. Инвентарь должен соответствовать окружению, а не только последнему commit основной ветки. Обновление фреймворка устраняет определённые ошибки его реализации, но не добавляет отсутствующую проверку владельца в вашем приложении.
Первичные источники: Next.js: безопасность данных · Next.js: переменные окружения
Продолжить: Мониторинг CVE и зависимостей вашего приложения
Практический чек лист релиза
Проверьте прямой вызов без сессии, чужой объект, запрещённое поле роли, минимальный DTO, клиентские артефакты и версию релиза. Изменения выполняйте на staging с тестовыми записями. В каждом запрете нужен положительный контроль владельца. Чек-лист можно использовать независимо от способа создания приложения: Cursor и другой редактор не меняют границы доверия HTTP-запроса.
Как включить повторение в процесс
Закрепите найденную ошибку регрессионным тестом, выполните ретест после деплоя и свяжите его с нужной сборкой. В CI используйте проверенный интерфейс Scantelio, а не случайный Action с похожим названием. Если аккаунт истёк или правило пропущено, процесс релиза должен обработать неполное покрытие явно. Публичный скан и проверка исходников дополняют друг друга, но не являются взаимозаменяемыми.
Продолжить: Как добавить проверки безопасности в CI/CD и GitHub Actions
Воспроизводимые примеры и материалы
Учебные данные — синтетические. Файлы не содержат действующих ключей или клиентской базы. Запускайте примеры только в собственной изолированной тестовой среде.
- Исходники минимального Next.js стенда (требует Next 16.4.3 и React)
- launch-checklist.csv — редактируемый шаблон
Протокол проверки примера: версии, действия и наблюдения

Вопросы и ответы
use server автоматически защищает действие?
Нет. Нужны проверка личности и разрешения на конкретную операцию и объект.
Достаточно middleware или proxy?
Они могут ограничивать вход, но права на объект нужно проверять в доверенном коде самой операции.
NEXT_PUBLIC скрывает ключ?
Нет. Это публичное назначение переменной, которая может попасть в браузерную сборку.
Можно передать весь user в компонент?
Сначала проверьте сериализуемые поля. Безопаснее сформировать минимальный DTO с данными, которые действительно нужны интерфейсу.
Обновление Next.js исправляет бизнес-логику?
Нет. Исправления фреймворка и правила доступа вашего приложения — разные задачи.
Сканер найдёт все ошибки Server Actions?
Нет. Вывод относится к поддерживаемым доступным сценариям и подготовленным данным, а не ко всем серверным функциям.
Автор и источники
Редакция Scantelio: методика и границы проверки. Проверка примера: 2026-11-02.
Перенесите проверку на свой проект
Проверить Next.js-приложениеВыберите свой проект после входа. Ничего не сканируется без подтверждения и согласия.
