Перейти к содержимому
Справочникобновлено 28 сентября 2026

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

ИИ пишет код, который работает, но не охраняет. Как за полчаса проверить приложение из браузера и понять, нужен ли специалист.

Чтение
8 мин
Для кого
Собственник, продакт, основатель MVP
Вопросов
2
Мысль за этим
002

Коротко

  1. Модели выбирают безопасный вариант кода примерно в 55% задач, и за два года эта цифра не выросла.
  2. Ломается скучное: кто что видит. Почти всё это ловится из браузера под двумя тестовыми пользователями.
  3. Есть персональные данные или деньги — перед запуском покажите приложение специалисту.

Работает ли код от нейросети, проверять почти бесполезно: работает он почти всегда. Проверять надо другое — кто что может увидеть и изменить. Мест пять: доступ к данным (таблицы и правила доступа к строкам, RLS), ключи в коде страницы, проверка входа и прав на сервере, зависимости и публичность самого проекта. Большую часть видно из браузера за полчаса, код читать не придётся.

Код от ИИ снаружи и внутри. Сверху окно приложения с зелёной оценкой A и надписью «работает». Под ним разрез: база данных с таблицами клиентов и заказов, у которой открыт замок, и ключ, лежащий в браузере
РИС. 01Фасад проходит любую проверку глазами. Дыра обычно этажом ниже.

Почему ИИ пишет рабочий, но дырявый код

Модель старается, чтобы заработало. Кнопка нажимается, данные сохраняются, экран красивый — задача выполнена. А вопрос «кто ещё может нажать эту кнопку» в запросе обычно не звучит, и сама модель его не задаст.

Цифры тут неприятные. 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чужой заказ
  • Код страницысекретный ключ
Б Посторонний
РИС. 02Одно и то же приложение. Разница только в том, откуда смотреть.

Как проверить приложение, сделанное нейросетью, за полчаса

Понадобятся браузер, два тестовых аккаунта и полчаса. Делайте на копии или до того, как пустили реальных клиентов.

Проверка двумя пользователями: ссылку на заказ пользователя А открывают под пользователем Б. Правильный ответ — «нет доступа», дыра — Б видит чужой заказ
РИС. 03Самая полезная проверка из всех. Никакого кода — только два окна браузера.
  1. Откройте приложение в окне инкогнито. Без входа не должно быть видно ничего, кроме того, что вы сознательно сделали публичным. Попробуйте прямые адреса: /admin, /dashboard, /settings.
  2. Заведите двух пользователей — А и Б. Под А создайте запись: заказ, заявку, документ. Скопируйте ссылку и откройте её под Б. Увидели чужое — главная дыра найдена.
  3. Поменяйте цифру в адресе. Если в ссылке есть номер записи, прибавьте единицу. Любая чужая карточка — повод остановить запуск.
  4. Проверьте базу. В Supabase откройте встроенный раздел проверок безопасности (Security Advisor): он подсвечивает таблицы без RLS. Любая таблица с людьми, заказами или деньгами без RLS — красный флаг.
  5. Поищите ключи в коде страницы. Откройте инструменты разработчика (F12), найдите поиск по всем файлам и введите «secret», «sk-», «service_role». Публичный ключ Supabase там быть может — так задумано. Секретный ключ, ключ от оплаты или нейросети — нет.
  6. Запустите встроенные проверки. В Lovable это сканирование перед публикацией, в Claude Code — команда /security-review. Считайте их результат нижней планкой, а не справкой.
  7. Задайте агенту вопрос с подвохом. В новой сессии: «Покажи, в каком месте сервер проверяет, что пользователь имеет право видеть этот заказ». Если ответ — «в интерфейсе» или «кнопка скрыта», проверки нет.
  8. Проверьте пакеты. Попросите агента перечислить все внешние библиотеки и для каждой дать ссылку на официальную страницу. Библиотека без страницы и истории — повод остановиться.
  9. Закройте проект. Убедитесь, что в настройках платформы и репозиторий, и черновые версии — приватные.

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

Отдельно о шаге 8. По сводке Cloud Security Alliance, около пятой части кода от ИИ ссылается на пакеты, которых не существует, — и злоумышленники заранее регистрируют такие имена.

Каждую найденную дыру отдавайте агенту по одной, с описанием, как её воспроизвести. После исправления повторите тот же шаг руками. «Исправил» от модели пока только слова.

Самопроверка перед запуском

Можно ли пускать людей0 из 9

Запускать рано. Начните с шагов 2 и 4 — там обычно самое дорогое.

РИС. 04Отметьте то, что проверили руками, а не то, что пообещал агент. Ничего не сохраняется.

Сам агент — тоже дверь

Проверяют обычно результат, но уязвимым бывает и инструмент. В сентябре Manifold Security показали: чужой репозиторий, открытый агентом, может выполнить команду на вашем компьютере через настройки git — ещё до того, как агент спросит разрешения. Уязвимость нашли в семи агентах, включая Claude Code, Codex и Cursor, и на момент публикации четыре варианта ещё не были закрыты.

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

Когда нужен человек: персональные данные и 152-ФЗ

Проверка из браузера закрывает самое очевидное. Она не заменит специалиста, если:

  • приложение хранит персональные данные — имена, телефоны, адреса;
  • принимает оплату или показывает финансовые данные;
  • подключено к внутренним системам компании — CRM, почте, складу;
  • им пользуется больше нескольких десятков человек.

Для России первый пункт теперь вопрос не только репутации, но и денег. С 30 мая 2025 года по 420-ФЗ утечка данных даже тысячи человек обходится компании от 3 до 5 млн ₽, а повторная — от 1 до 3% годовой выручки, до 500 млн ₽. Несколько часов аудита на этом фоне — округление.

Вайбкодинг забрал дорогую часть работы — написать. Осталась часть, дешёвая с виду и дорогая по последствиям: решить, кто что видит. Модель её за вас не решит, её об этом никто не спрашивал. Полчаса с двумя тестовыми пользователями всё равно дешевле письма клиентам о том, что их данные утекли. А где ещё стоит держать модель на коротком поводке, я писал в эссе про вайбкодинг.

Частые вопросы

Что такое RLS в Supabase и почему о нём все пишут?

RLS (row-level security, защита на уровне строк) — правила, которые решают, какие строки таблицы видит конкретный пользователь. Если таблица в открытой схеме без RLS, её может прочитать и изменить любой, у кого есть публичный ключ приложения, а он лежит в браузере у каждого посетителя.

Можно ли попросить ИИ исправить уязвимости самого себя?

Можно и нужно, но в отдельной сессии и с конкретной задачей, например «покажи, где сервер проверяет, что заказ принадлежит этому пользователю». На общую просьбу «сделай безопасно» модель уверенно ответит и мало что поменяет. Результат всё равно проверяйте руками из браузера.

Мысль за этим · 002 · РазборС вайбкодингом я не стал быстрее. Я стал иначе ошибатьсяРаньше ошибка стоила неделю чужой работы, и я старался её не совершать. Теперь она стоит вечер — моего.Читать эссе · 4 мин