Собрали MVP через AI? Проверьте, что вместе с ним не открыли базу и ПДн

MVP быстро собирается через Cursor, Claude, Codex или другой AI-инструмент. Страницы готовы, серверная часть работает, форма принимает заявки, в базе появляются первые записи. Пора наконец переключиться с бесконечной разработки на пользователей и первые деньги.

Снаружи выглядит всё хорошо. Но под капотом может быть совсем другая история. Во время настройки к базе открыли доступ извне, чтобы подключиться с ноутбука. Внутреннюю админку не закрыли нормально: всё равно ссылку никто не знает. Swagger спокойно показывает устройство API любому, кто до него доберётся.

Потом появляются первые симптомы, которые обычно выглядят безобидно. Сайт то тормозит, то снова работает нормально. База отвечает чуть дольше обычного. В логах мелькает чужая активность, но её легко списать на обычный интернет-шум.

А затем выясняется, что сервис уже нашли боты. Кто-то мог получить доступ к серверу или данным, а быстрый MVP превратился в риск утечки ПДн и юридическую головную боль.

Для владельца продукта MVP - это проверка гипотезы. Для интернета - обычный публичный сервис.

Ботам всё равно, сколько у вас пользователей. Им всё равно, есть ли у вас бренд, выручка и команда.

Они просто обходят адреса и смотрят, что отвечает.

Открыт порт? Проверим.

Есть Swagger? Посмотрим API.

Есть админка? Попробуем зайти.

Есть база наружу? Проверим доступы.

Есть известная уязвимость? Попробуем использовать.

Работающий демо-экран ещё не означает готовность. Между ним и нормальным запуском лежит скучный слой технической гигиены: порты, доступы, секреты, логи, SSL, backup и понимание, где хранятся персональные данные.

Сканерам всё равно, сколько у вас пользователей, есть ли бренд и показывали ли вы продукт кому-то кроме друзей. Для них ваш MVP - просто ещё один адрес в интернете, который можно проверить на открытые порты, слабые настройки и забытые панели.

Автоматические инструменты 24/7 сканируют интернет и ищут всё, что случайно осталось доступным снаружи: открытые сервисы, панели управления, API-документацию и слабые настройки.

В исследовании Sophos один из honeypot-серверов получил первую атаку через 52 секунды после появления в интернете, а в среднем такие серверы получали 13 попыток атак в минуту.

Маленький проект даже удобнее крупного. У него меньше мониторинга, чаще используются дефолтные настройки, а владелец может неделями не смотреть логи.

Представим типовую ситуацию.

Вы запустили свой MVP на VPS. Приложение работает. PostgreSQL слушает порт 5432. Во время настройки было удобно подключаться к базе напрямую с ноутбука, поэтому порт оставили открытым наружу.

Потом переключились на фичи, интерфейс и демонстрацию клиентам.

Дальше возможна цепочка:

1. Сервер попадает в автоматическое сканирование.
2. Снаружи находится открытый PostgreSQL (Redis, SSH или админка).
3. Проверяются стандартные доступы, слабые пароли, дефолтные настройки или известные уязвимости.
4. Если доступ получен, на сервере может появиться майнер, новый пользователь, лишняя cron-задача или изменённый контейнер.

И здесь важный момент: закрыть порт после обнаружения проблемы - не всегда достаточно.

Если доступ уже получили, нужно проверять не только firewall. Нужно понять, был ли сервер скомпрометирован: пользователи, SSH-ключи, cron, systemd, контейнеры, секреты, токены, доступы к БД, CI/CD, логи, дампы, репозиторий.

Мысль "закрыл 5432, теперь всё нормально" не соответствует действительности. Закрытый порт устраняет только текущую доступность сервиса из интернета. Но он не отвечает на вопрос, успел ли кто-то зайти внутрь раньше.

Если сайт собирает имя, телефон, email, Telegram, адрес, заявку, комментарий, файл, заказ, резюме, данные клиента, cookie или данные веб-аналитики, это уже может относиться к персональным данным.

По 152-ФЗ оператор персональных данных обязан принимать правовые, организационные и технические меры для защиты данных от неправомерного или случайного доступа, уничтожения, изменения, копирования, распространения и других неправомерных действий.

И задача сводится не только к тому, чтобы добавить текст политики в футер. Политика обработки персональных данных - это не декоративная ссылка. Важно, какие данные реально собираются, где они хранятся, кто имеет к ним доступ, как они защищены и что происходит при инциденте.

Если данные утекли, проблема перестаёт быть только технической. Появляются юридические последствия.

ИИ отлично ускоряет запуск. С его помощью можно быстро собрать прототип. Но особенность в том, что генеративная модель отвечает на поставленную задачу.

Если вы попросили "сделай страницу с формой", она будет решать задачу сайта и формы. Она не обязана думать и проводить полноценный security-review.

Она не проверяет реальный сервер, firewall, DNS, CI/CD, логи и доступы, если вы отдельно не поставили такую задачу.

А если поставили, результат всё равно нужно проверять инженерно: на реальной инфраструктуре, с реальными настройками, доступами и логами.

AI ускоряет разработку, но не заменяет инженерную ответственность за запуск.

Главный риск vibe coding в том, что продукт появляется быстрее, чем у владельца успевает сформироваться понимание, какая именно на нем теперь ответственность и что именно теперь доступно злоумышленникам.

В vibe coding многие смотрят на результат глазами пользователя: сайт открылся, форма отправилась, бот ответил, база записала данные.

Но модель часто оставляет технические допущения, которые в демо почти не видны: "авторизацию добавим позже", "CORS пока открыт", "база будет закрыта firewall", "секреты потом вынесем", "dev-endpoint временный".

Иногда это доходит до абсурда: вредоносный npm-пакет засветил собственный GitHub-токен. Его вайб-кодили, чтобы воровать данные, но секреты в коде в итоге выдали самого автора.

Именно эти незаметные "потом" часто уезжают в реальный релиз.

Для демо это может пройти незаметно. Сайт открылся, форма отправилась, база записала заявку - значит, кажется, всё работает.

Но production ломается не только на явных ошибках. Он ломается на местах, где кто-то сделал временное допущение и забыл к нему вернуться.

ИИ часто пишет так, как будто рядом есть инженер, который потом пройдёт по всем TODO, заменит placeholders, проверит доступы, настроит секреты, закроет порты, разделит dev/prod и уберёт временные обходы.

Но если этого инженера нет, все эти "потом заменим" остаются в реальном продукте.

Перед запуском сайта, MVP или веб-приложения не обязательно сразу делать большой корпоративный аудит. Но базовую техническую гигиену пропускать нельзя.

Минимальный чек-лист:

Этот список не делает проект неуязвимым. Но он убирает очевидные ошибки, которые часто остаются после быстрого запуска.

OWASP относит к security misconfiguration отсутствие hardening, лишние включённые порты, сервисы, страницы, аккаунты, права и дефолтные пароли. То есть это как раз те "мелкие настройки", которые часто остаются после быстрого запуска.

MVP может быть собран очень быстро. Это плюс. Но скорость запуска не снимает ответственность.

Перед запуском MVP нужно проверять не только интерфейс и фичи, но и инфраструктуру: порты, базу, секреты, формы, SSL, доступы, логи, backup, обработку персональных данных и временные решения, которые могли остаться после AI-разработки.

Если у вас уже есть vibe-coded проект, но перед запуском хочется спокойно проверить код, деплой, формы, SSL, аналитику, безопасность и обработку ПДн - начните с mvp2prod.ru