Безопасность приложения, написанного нейросетью: чек-лист из 15 пунктов
Безопасность проекта, написанного нейросетью, проверяется по пяти направлениям: секреты и ключи, доступ к данным в базе, авторизация, внешние интеграции и зависимости. Чек-лист из 15 пунктов ниже помогает быстро понять, где слабые места, до того как пускать на проект настоящих пользователей.
Коротко
- Чек-лист закрывает пять направлений: секреты, доступ к данным, авторизация, интеграции, зависимости.
- Самые частые находки — ключи в коде и отсутствие политик доступа к базе данных.
- Каждый пункт можно проверить самостоятельно за несколько минут.
- Это ориентир для самопроверки, а не замена полноценного аудита.
- Список применим к проектам на Lovable, Bolt, Cursor, Claude Code и похожих инструментах.
Что это и когда возникает
ИИ-инструменты хорошо генерируют работающий код, но редко сами задумываются о безопасности — это требует понимания угроз, а не просто решения конкретной задачи. Проверка нужна перед тем, как на проект придут настоящие пользователи, особенно если есть регистрация, платежи или личные данные.
Чек-лист из 15 пунктов
| № | Пункт | Направление |
|---|---|---|
| 1 | Ключи API не лежат в клиентском коде | Секреты |
| 2 | Ключи API не попали в публичный репозиторий | Секреты |
| 3 | Переменные окружения не захардкожены в коде | Секреты |
| 4 | В базе данных включены и настроены политики доступа (RLS) | Доступ к данным |
| 5 | Тестовые данные отделены от реальных пользовательских | Доступ к данным |
| 6 | Нет доступа к чужим данным через прямой запрос по ID | Доступ к данным |
| 7 | Авторизация не «отваливается» при обычном использовании | Авторизация |
| 8 | Восстановление пароля работает и не раскрывает лишнего | Авторизация |
| 9 | Роли и права разграничены, а не проверяются только на фронтенде | Авторизация |
| 10 | Формы проверяются на сервере, а не только в браузере | Интеграции |
| 11 | Платёжные вебхуки проверяют подпись запроса | Интеграции |
| 12 | Внешние API-ключи имеют ограниченные права, а не полный доступ | Интеграции |
| 13 | Зависимости (библиотеки) обновлялись за последние несколько месяцев | Зависимости |
| 14 | Нет известных уязвимостей в используемых пакетах | Зависимости |
| 15 | Есть логи, по которым видно, что произошло при инциденте | Зависимости |
Сколько стоит и из чего складывается цена
Самопроверка по чек-листу бесплатна. Если по его итогам нужен полноценный аудит с исправлениями — это заказ под ключ от 50 000 ₽, срок называю после диагностики. Точечное закрытие одного-двух пунктов можно оплатить по часам от 3 000 ₽/час.
Сколько стоит содержать
После первого аудита имеет смысл периодически (например, раз в несколько месяцев) обновлять зависимости и перепроверять политики доступа, если менялась структура данных — это можно включить в почасовое сопровождение.
Что ломается в эксплуатации
Самая опасная ситуация — когда пункт отмечен как решённый один раз, но перестаёт быть верным после следующей доработки через ИИ: например, новая таблица в базе данных создаётся без политик доступа по умолчанию.
Когда это не нужно
Если проект — это внутренний прототип без реальных пользователей и без личных данных, полноценная проверка безопасности может подождать до момента, когда проект станет публичным.
Что спросить у подрядчика
- По какому чек-листу или методике проверяете безопасность?
- Что из найденного критично, а что можно отложить?
- Исправляете найденное сами или только составляете отчёт?
- Как убедиться, что исправление действительно закрыло проблему?
- Что делать, если похожая уязвимость появится после следующей доработки?
Как это сделано у меня
Аудит безопасности — часть направления ВайбФикс: прохожу по всем 15 пунктам, присылаю отчёт с приоритетами и закрываю найденное.
Частые вопросы
Этот чек-лист заменяет полноценный аудит безопасности?
Нет, это ориентир для самопроверки. Полноценный аудит смотрит в код и доступы и находит то, что по общим пунктам не видно.
Сколько из 15 пунктов обычно нарушены в проектах на ИИ?
По опыту — чаще всего встречаются проблемы с секретами в коде и отсутствием политик доступа к данным; остальное реже, но тоже регулярно.
С чего начать, если отметили сразу несколько пунктов?
С самого рискованного — обычно это открытые ключи API и доступ к данным без ограничений. Остальное можно закрывать по приоритету.
Ещё по теме
Разработчик. Пишу о починке проектов на ИИ и ИИ-автоматизации на основе своей практики. Подробнее — как я работаю.
Если Telegram не открывается: MAX · oongemakh@gmail.com
Обновлено: