Безопасность кода от ИИ — что проверить перед запуском, если вы не читаете код
ИИ пишет код, который работает, но не охраняет. Как за полчаса проверить приложение из браузера и понять, нужен ли специалист.
- Чтение
- 8 мин
- Для кого
- Собственник, продакт, основатель MVP
- Вопросов
- 2
- Мысль за этим
- 002
Коротко
- Модели выбирают безопасный вариант кода примерно в 55% задач, и за два года эта цифра не выросла.
- Ломается скучное: кто что видит. Почти всё это ловится из браузера под двумя тестовыми пользователями.
- Есть персональные данные или деньги — перед запуском покажите приложение специалисту.
Работает ли код от нейросети, проверять почти бесполезно: работает он почти всегда. Проверять надо другое — кто что может увидеть и изменить. Мест пять: доступ к данным (таблицы и правила доступа к строкам, RLS), ключи в коде страницы, проверка входа и прав на сервере, зависимости и публичность самого проекта. Большую часть видно из браузера за полчаса, код читать не придётся.
Почему ИИ пишет рабочий, но дырявый код
Модель старается, чтобы заработало. Кнопка нажимается, данные сохраняются, экран красивый — задача выполнена. А вопрос «кто ещё может нажать эту кнопку» в запросе обычно не звучит, и сама модель его не задаст.
Цифры тут неприятные. Veracode прогнал больше 150 моделей по одним и тем же задачам: синтаксически верен больше 95% кода, а безопасный вариант выбран примерно в 55% случаев. Два года назад было столько же. Умнее модели стали, осторожнее — нет. От межсайтового скриптинга (XSS) защищаются лишь в 15% задач.
Исследователи, разобравшие 200 развёрнутых вайбкод-приложений, нашли хотя бы одну уязвимость в 91% из них, и около двух третей находок — критические или высокие. Лидеры списка — сломанный контроль доступа, инъекции и ошибки входа. Никакой экзотики, сплошь азбука.
Типичные уязвимости кода от ИИ
Если свести исследования Wiz, Escape и Reeve, картина скучная. И это хорошая новость: скучное легко проверить.
- Открытые таблицы. База без правил доступа. В документации Supabase прямо сказано: таблица в открытой схеме без RLS доступна на чтение и запись любому, у кого есть публичный ключ. А он есть у каждого посетителя сайта.
- Ключи в браузере. Секретный ключ от платёжки или нейросети вшит в код страницы. Escape, проверив 5 600 приложений, нашёл больше 400 утёкших секретов.
- Вход, который проверяет браузер. Кнопка «Админка» спрятана, но сама страница открывается по прямой ссылке. Или пароль сравнивается прямо в коде страницы.
- Чужое по ссылке. В адресе /orders/1052 меняешь цифру — и видишь чужой заказ. Это и есть «сломанный контроль доступа», самая частая находка.
- Публичный по умолчанию проект. По данным RedAccess, которые приводит Axios, около 5 000 приложений на популярных платформах открывали данные компаний — от переписки с клиентами до внутренних финансов банка. Причина — проекты были публичными, пока их не закрыли вручную.
- Входработает
- Заказытолько мои
- Сканероценка A
- Таблица клиентовчитается без входа
- /orders/1053чужой заказ
- Код страницысекретный ключ
Как проверить приложение, сделанное нейросетью, за полчаса
Понадобятся браузер, два тестовых аккаунта и полчаса. Делайте на копии или до того, как пустили реальных клиентов.
- Откройте приложение в окне инкогнито. Без входа не должно быть видно ничего, кроме того, что вы сознательно сделали публичным. Попробуйте прямые адреса: /admin, /dashboard, /settings.
- Заведите двух пользователей — А и Б. Под А создайте запись: заказ, заявку, документ. Скопируйте ссылку и откройте её под Б. Увидели чужое — главная дыра найдена.
- Поменяйте цифру в адресе. Если в ссылке есть номер записи, прибавьте единицу. Любая чужая карточка — повод остановить запуск.
- Проверьте базу. В Supabase откройте встроенный раздел проверок безопасности (Security Advisor): он подсвечивает таблицы без RLS. Любая таблица с людьми, заказами или деньгами без RLS — красный флаг.
- Поищите ключи в коде страницы. Откройте инструменты разработчика (F12), найдите поиск по всем файлам и введите «secret», «sk-», «service_role». Публичный ключ Supabase там быть может — так задумано. Секретный ключ, ключ от оплаты или нейросети — нет.
- Запустите встроенные проверки. В Lovable это сканирование перед публикацией, в Claude Code — команда /security-review. Считайте их результат нижней планкой, а не справкой.
- Задайте агенту вопрос с подвохом. В новой сессии: «Покажи, в каком месте сервер проверяет, что пользователь имеет право видеть этот заказ». Если ответ — «в интерфейсе» или «кнопка скрыта», проверки нет.
- Проверьте пакеты. Попросите агента перечислить все внешние библиотеки и для каждой дать ссылку на официальную страницу. Библиотека без страницы и истории — повод остановиться.
- Закройте проект. Убедитесь, что в настройках платформы и репозиторий, и черновые версии — приватные.
Встроенным проверкам из шага 6 не стоит верить на слово: и Lovable, и Anthropic прямо пишут, что их проверки не заменяют полноценную. Сканер найдёт открытую таблицу, но не поймёт, что пользователь Б не должен видеть заказ Анны.
Отдельно о шаге 8. По сводке Cloud Security Alliance, около пятой части кода от ИИ ссылается на пакеты, которых не существует, — и злоумышленники заранее регистрируют такие имена.
Каждую найденную дыру отдавайте агенту по одной, с описанием, как её воспроизвести. После исправления повторите тот же шаг руками. «Исправил» от модели пока только слова.
Самопроверка перед запуском
Запускать рано. Начните с шагов 2 и 4 — там обычно самое дорогое.
Сам агент — тоже дверь
Проверяют обычно результат, но уязвимым бывает и инструмент. В сентябре Manifold Security показали: чужой репозиторий, открытый агентом, может выполнить команду на вашем компьютере через настройки git — ещё до того, как агент спросит разрешения. Уязвимость нашли в семи агентах, включая Claude Code, Codex и Cursor, и на момент публикации четыре варианта ещё не были закрыты.
Отсюда два простых правила: не скармливайте агенту архивы и репозитории от незнакомых людей и обновляйте инструменты. Агент работает с вашими ключами и доступами, значит, и ошибается с ними же. Правило то же, что для ИИ-агентов в бизнесе: минимум прав на старте, расширение — только после проверки.
Когда нужен человек: персональные данные и 152-ФЗ
Проверка из браузера закрывает самое очевидное. Она не заменит специалиста, если:
- приложение хранит персональные данные — имена, телефоны, адреса;
- принимает оплату или показывает финансовые данные;
- подключено к внутренним системам компании — CRM, почте, складу;
- им пользуется больше нескольких десятков человек.
Для России первый пункт теперь вопрос не только репутации, но и денег. С 30 мая 2025 года по 420-ФЗ утечка данных даже тысячи человек обходится компании от 3 до 5 млн ₽, а повторная — от 1 до 3% годовой выручки, до 500 млн ₽. Несколько часов аудита на этом фоне — округление.
Вайбкодинг забрал дорогую часть работы — написать. Осталась часть, дешёвая с виду и дорогая по последствиям: решить, кто что видит. Модель её за вас не решит, её об этом никто не спрашивал. Полчаса с двумя тестовыми пользователями всё равно дешевле письма клиентам о том, что их данные утекли. А где ещё стоит держать модель на коротком поводке, я писал в эссе про вайбкодинг.
Частые вопросы
Что такое RLS в Supabase и почему о нём все пишут?
RLS (row-level security, защита на уровне строк) — правила, которые решают, какие строки таблицы видит конкретный пользователь. Если таблица в открытой схеме без RLS, её может прочитать и изменить любой, у кого есть публичный ключ приложения, а он лежит в браузере у каждого посетителя.
Можно ли попросить ИИ исправить уязвимости самого себя?
Можно и нужно, но в отдельной сессии и с конкретной задачей, например «покажи, где сервер проверяет, что заказ принадлежит этому пользователю». На общую просьбу «сделай безопасно» модель уверенно ответит и мало что поменяет. Результат всё равно проверяйте руками из браузера.