Security review помогает найти уязвимости в сайте или приложении до публикации и проверить, что останется доступно постороннему пользователю. Для небольшого бизнеса такую проверку можно провести по понятному чек-листу: изучить доступы, настройки, зависимости, работу с ключами и типовые сценарии. ИИ-сгенерированный код тоже нужно проверять вручную: аккуратный интерфейс не показывает, безопасно ли приложение обрабатывает запросы и хранит секреты.
С чего начать проверку безопасности?
Сначала составьте короткое описание проекта: какие страницы и функции доступны, кто ими пользуется, какие внешние сервисы подключены. Отдельно перечислите учётные записи, API-ключи, базы данных и места, где размещён сайт. Такая карта помогает не пропустить компонент, который ИИ добавил во время разработки, а владелец проекта о нём не знает.
Затем разделите проверки на три группы: код, настройки и поведение приложения. Для каждой функции запишите, кто может её вызвать и что должно произойти. Например, посетитель сайта видит каталог, а изменение его содержимого доступно только сотруднику с соответствующим доступом. Проверяйте именно границу между этими ролями.
- Определите страницы и действия, доступные без входа в систему.
- Запишите, кто может менять настройки и содержимое.
- Перечислите внешние сервисы и ключи, с которыми работает проект.
- Найдите адреса тестовой и рабочей версий сайта.
Если проект создавался с помощью ИИ-агента, попросите его перечислить изменённые файлы и подключённые библиотеки. Используйте ответ как подсказку, а не как заключение: агент может не заметить собственную ошибку или описать проверку, которую фактически не выполнял.
Что проверить в коде и настройках?
Начните с секретов: паролей, токенов и ключей доступа. Они не должны попадать в открытые файлы проекта, историю изменений или сообщения об ошибках, доступные посетителю. Если секрет уже попал в репозиторий, удаление строки не всегда решает проблему: ключ нужно заменить в сервисе, который его выдал, а затем проверить, где ещё он использовался.
Проверьте права доступа на сервере и внутри приложения. Скрытая кнопка сама по себе не ограничивает действие: сервер тоже должен отказать пользователю без нужных прав. Попробуйте открыть административную страницу напрямую и отправить запрос от обычной учётной записи. Ожидаемый результат — отказ, а не изменение данных.
Посмотрите, какие библиотеки и компоненты использует проект. Удалите ненужные зависимости, а для оставшихся проверьте, доступны ли обновления и нет ли предупреждений о проблемах безопасности. Обратите внимание на настройки публикации: тестовые страницы, режим отладки и диагностические сообщения не должны случайно открывать служебные данные.
Отдельно проверьте ввод, который приложение принимает от посетителей: поля форм, параметры в адресной строке, загружаемые файлы. Перед сохранением и обработкой приложение должно проверять формат и допустимые значения. Для файла задайте понятные ограничения по типу и размеру; не полагайтесь только на проверку в браузере, потому что запрос можно отправить в обход формы.
Как проверить приложение вручную?
Пройдите основные сценарии как обычный посетитель и как пользователь с ограниченными правами. Проверяйте не только ожидаемый путь, но и соседние варианты: пустое поле, слишком длинный текст, неверный формат, повторное нажатие кнопки. Зафиксируйте, что вы ввели и что увидели в ответ. Для сайта с формой заявки проверьте, например, что некорректные данные не создают запись и не выводят техническую информацию.
К проверке можно добавить автоматические тесты пользовательских сценариев. Они помогают повторять одни и те же действия после изменений и замечать, если новая функция сломала старую. Инструкцию по подготовке таких проверок даёт материал о тестах пользовательских сценариев в вайбкодинг-проекте. Но тесты не заменяют проверку прав, секретов и конфигурации: сценарий может проходить успешно и при этом не замечать уязвимость.
Сгенерированные ИИ тесты тоже нужно перепроверить. Убедитесь, что тест действительно завершается ошибкой при неправильном результате, а не всегда сообщает об успехе. Для этого измените ожидаемое поведение или временно внесите контролируемую ошибку и проверьте, что тест её обнаружит. Такой подход согласуется с рекомендациями по проверке AI-generated code (QATools, «Тестирование AI-generated code: риски, метрики и процесс контроля качества»).
Какие ошибки встречаются при security review?
- Считать ответ ИИ доказательством безопасности. Просите объяснить, какие файлы и сценарии он проверил, а затем сверяйте это вручную.
- Проверять только внешний вид сайта. Откройте адреса и действия, которые интерфейс скрывает от обычного посетителя.
- Оставлять ключи в коде после тестирования. Замените раскрытый ключ и уберите его из текущих файлов проекта.
- Запускать сгенерированный код сразу на рабочем сайте. Сначала проверьте изменения на отдельной тестовой версии.
- Проверить приложение один раз и забыть о нём. Повторяйте основные проверки после крупных изменений и перед публикацией новой версии.
Код, созданный или изменённый ИИ, следует считать непроверенным до ручного ревью: такую практику рекомендуют специалисты по безопасности, описанные в материале о рисках вайбкодинга (Comss.ru, «Чем опасен вайб-кодинг: данные METR, Georgia Tech и Wiz»). Если найденная проблема затрагивает доступы, ключи или рабочие данные, остановите публикацию и привлеките разработчика, который сможет проверить причину и подтвердить исправление.
Чтобы провести первичный review на этой неделе, составьте список функций и доступов, проверьте ключи и настройки публикации, затем пройдите сценарии с обычной и ограниченной учётной записью. Запишите каждую найденную проблему, назначьте ответственного и повторите проверку после исправления. Такой список даст понятную основу для следующего релиза и разговора с техническим специалистом.