Вайб-кодинг без счёта на 337 000 ₽: 7 проверок безопасности приложения, которое собрала нейросеть (2026)

Проверить безопасность приложения, которое собрала нейросеть, можно за вечер и без знания программирования. Хватает семи проверок: ключи API не лежат в открытом коде, в OpenAI и Anthropic стоит жёсткий лимит трат, платные запросы идут через сервер, база закрыта правилами доступа, права проверяются на сервере, ввод пользователей фильтруется, а формы ограничены по частоте запросов.

Зачем это делать, если всё и так работает? Работающее приложение и защищённое приложение живут в разных измерениях. Нейросеть пишет код, который открывается в браузере и радует глаз, а про то, что любой посетитель может вытащить из него твой ключ OpenAI, она молчит. Zapier в своём разборе описывает типичный сценарий: чужие люди находят ключ и накручивают счёт на 4000 долларов. По курсу ЦБ на 17 сентября 2026 года (84,17 ₽) это около 337 000 ₽, и оплачивать их придётся тебе.

Коротко: пять слов, без которых дальше будет непонятно

• Ключ API - пароль, по которому сервис вроде OpenAI понимает, с чьего счёта списывать деньги за запрос.
• Фронтенд - всё, что загружается в браузер посетителя. Любой может открыть этот код и прочитать.
• Бэкенд, серверная функция - код, который выполняется у тебя на сервере. Посетитель видит только результат.
• .env - файл с секретами, который живёт на твоём компьютере и на хостинге, но не попадает в git.
• RLS (Row Level Security) - правила в базе данных, которые решают, какой пользователь какие строки видит и меняет.

Насколько это реальная угроза: цифры 2025-2026

Цифры неприятные. По отчёту Veracode за 2025 год, 45% кода, который пишут нейросети, содержит уязвимости. Модели уверенно генерируют рабочие функции и так же уверенно пропускают проверки доступа.

В мае 2026 года исследователи из компании RedAccess под руководством Дора Цви просканировали тысячи приложений, собранных в Lovable, Replit, Base44 и Netlify. Больше 5000 из них не имели вообще никакой защиты или авторизации. Примерно 40% отдавали наружу чувствительные данные: медицинские сведения, финансовые записи, корпоративные презентации и стратегии, полные логи переписок клиентов с чат-ботами. 7 мая 2026 года эти результаты опубликовал Wired.

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

Чем это грозит лично тебе, если ты собрал сайт или бота для себя или клиента:

1. Счёт за чужое использование. Украденный ключ OpenAI или Claude превращается в бесплатный доступ к моделям для кого угодно. Платишь ты.
2. Утечка данных. Имена, телефоны, переписки твоих пользователей уходят в открытый доступ.
3. Захват приложения. Посетитель даёт себе права администратора и удаляет записи, меняет цены, рассылает спам от твоего имени.
4. Репутация и деньги бизнеса. Клиент, чьи данные утекли, к тебе не вернётся.

Для России есть пятый пункт, юридический. С 30 мая 2025 года за утечку персональных данных от 1000 до 10 000 человек гражданину грозит штраф 100-200 тысяч рублей, компании 3-5 миллионов. Об утечке нужно уведомить Роскомнадзор в течение 24 часов, за молчание штраф отдельный, от 1 до 3 миллионов для организации.

Проверка 1. Где хранить ключ API, чтобы его не украли

Это самая частая и самая дорогая дыра. Нейросеть, чтобы быстро показать результат, вставляет ключ прямо в код страницы. Код страницы уходит в браузер каждому посетителю. Дальше дело техники: открыть инструменты разработчика и скопировать строку, начинающуюся с sk-.

Правила для любого секрета (ключи OpenAI, Anthropic, Stripe, SendGrid, токены ботов):

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

Как сделать правильно, по шагам:

1. Создай в корне проекта файл .env и положи туда ключ строкой вида OPENAI_API_KEY=sk-твой-ключ.
2. Открой .gitignore и допиши туда .env. Без этого файл уедет на GitHub при первом же коммите.
3. В коде обращайся к ключу только через переменную окружения.
4. На хостинге (Vercel, Netlify, Cloudflare Pages) пропиши тот же ключ в разделе переменных окружения проекта.
5. Задеплой заново, чтобы хостинг подхватил переменную.

Если ключи уже засвечены, порядок такой: заведи .env, замени все видимые ключи ссылками на переменные, удали старые ключи в кабинетах сервисов, создай новые, впиши их в .env, обнови переменные окружения на хостинге и задеплой. Про то, как держать такие правила в голове агента постоянно, у нас есть отдельный разбор настройки CLAUDE.md: туда стоит один раз записать «секреты только через .env», и Claude Code перестанет вставлять ключи в код.

Проверка 2. Как поставить лимит трат в OpenAI и Anthropic

Даже идеально спрятанный ключ может утечь: через подрядчика, через старый ноутбук, через заражённое расширение. Лимит трат превращает катастрофу на сотни тысяч рублей в неприятность на сумму, которую ты сам выбрал. Это самая дешёвая страховка из всех семи проверок.

Лимит трат в OpenAI API

1. Зайди на platform.openai.com и открой нужный проект.
2. Перейди в настройки проекта, раздел Limits.
3. В блоке Spend нажми Edit spend limit и впиши месячную сумму.
4. Включи переключатель Enforce a hard limit. Это главное действие во всей инструкции.
5. Сохрани. Тот же лимит можно поставить на уровне всей организации.

Без жёсткого лимита ты получишь только оповещение, а запросы продолжат списывать деньги. С жёстким лимитом после достижения порога API отвечает ошибкой 429 с кодом project_spend_limit_exceeded. Оповещения при этом продолжают работать, так что можно поставить письмо на 50% и блокировку на 100%.

Лимит трат в Claude API (Anthropic)

У Anthropic лимиты живут в рабочих пространствах, и тут есть ловушка. На Default Workspace, куда по умолчанию попадают все ключи, лимиты поставить нельзя. Значит, ключ из него ограничен только общим потолком организации.

1. В Claude Console открой Settings, затем Workspaces, нажми Create workspace и назови его по имени приложения.
2. Переключись в новое пространство селектором в левом верхнем углу и выпусти API-ключ внутри него.
3. Открой настройки пространства, вкладку Spend limits, задай месячный потолок и пороги оповещений.
4. На вкладке Rate limits ограничь число запросов и токенов в минуту, если приложению столько не нужно.
5. Старый ключ из Default Workspace удали, если приложение работало на нём.

Лимит пространства может быть только ниже лимита организации, выше не получится. Это удобно: одно приложение с утёкшим ключом не съест бюджет остальных проектов.

Как оплатить API OpenAI и Anthropic из России

Оба сервиса официально не работают с Россией: зарегистрироваться и пользоваться консолью получится только через рабочий VPN, а российские карты не принимаются ни в OpenAI, ни в Anthropic. Пополнить баланс API можно зарубежной картой или через сервис оплаты подписок, который закидывает деньги на твой аккаунт за рубли (реферальная ссылка: тебе тот же прайс, мне небольшой процент). Подробнее все способы с ценами разобраны в гайде как оплатить Claude из России.

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

Проверка 3. Какой код нельзя оставлять во фронтенде

Правило простое: всё, что видит браузер, может изменить посетитель. Если скидка считается на странице, посетитель поставит себе скидку 100%. Если цена заказа уходит на оплату из браузера, он отправит цену в 1 рубль.

Для серверного кода не нужен свой сервер. Подходят облачные функции: Supabase Edge Functions, Firebase Cloud Functions, Vercel Functions, Cloudflare Workers. Ключ лежит в переменных окружения функции, браузер отправляет запрос функции, функция идёт в OpenAI и возвращает ответ.

Попроси агента одной фразой: «Перенеси все вызовы платных API, расчёт цен и проверку прав в серверные функции. Во фронтенде не должно остаться ни одного секретного ключа».

Проверка 4. Как закрыть базу данных: RLS в Supabase и правила Firestore

Вторая по частоте дыра после ключей. Supabase и Firebase дают фронтенду публичный ключ для работы с базой. Это нормально и задумано так, но только при условии, что сама база закрыта правилами. Нейросети часто создают таблицы и забывают про правила. Результат: любой человек с публичным ключом (а он лежит в коде страницы) читает, меняет и удаляет всё.

Что проверить в Supabase:

1. Открой проект, раздел таблиц. Таблицы без RLS Supabase помечает предупреждением, а владельцу приходит письмо.
2. Включи RLS на каждой таблице в схеме public.
3. Убедись, что у каждой таблицы есть хотя бы одна политика. Включённый RLS без политик закрывает таблицу полностью, и приложение сломается, это нормальный сигнал, что политики надо дописать.
4. Загляни в Security Advisor, он подсвечивает таблицы без RLS и слишком широкие политики.

В Firebase и Firestore RLS нет, там то же самое делают правила безопасности (Security Rules). Проверь, что в них нет режима «разрешить всё», с которым проект создаётся для тестов.

Если что-то в базе уже пошло не так и данные пропали, у нас есть отдельный playbook на случай, когда ИИ удалил базу.

Проверка 5. Кто что может: права пользователей на сервере

Разлогиненный посетитель должен видеть только публичные страницы и публичные данные. Это звучит очевидно, а на практике в вайб-приложениях админка часто спрятана лишь тем, что на неё нет кнопки.

Как выстроить права:

1. Регистрацию и вход отдай готовой платформе: Supabase Auth, Firebase Authentication, Clerk или Auth0. Самописная авторизация от нейросети почти всегда дырявая.
2. При регистрации записывай пользователю поле с уровнем доступа: обычный, платный, админ.
3. Перед каждым защищённым действием (удалить запись, выдать доступ, открыть админку) проверяй этот уровень на сервере. Проверка в браузере не считается, её отключают за минуту.
4. Не давай пользователю самому менять своё поле роли, закрой это политикой в базе.

Проверка 6. Что пользователь может отправить в твоё приложение

Любое поле ввода - это дверь. Через неё приходят не только имена и отзывы.

• Валидация полей. Почта должна быть похожа на почту, число на число, длина текста ограничена. Проверка нужна и в форме, и на сервере.
• Весь пользовательский текст показывай как обычный текст. Если отзыв посетителя вставляется на страницу как HTML, в отзыв можно вписать скрипт, и он выполнится у всех, кто откроет страницу.
• Отдавай только нужные поля. Если странице профиля нужны имя и аватар, запрос к базе должен возвращать ровно эти два поля. Если прилетает вся строка с телефоном, почтой и историей заказов, её видно в инструментах разработчика.
• Загрузка файлов. Храни файлы в отдельном сервисе (Supabase Storage, Cloudinary), ограничь допустимые типы и в форме, и на сервере, а на сервере проверяй реальную сигнатуру файла по первым байтам. Расширение .jpg в имени ничего не гарантирует.

Проверка 7. Лимит запросов и защита от ботов

Это защита от второго сценария разорения. Ключ может быть спрятан идеально, но если твоя серверная функция обращается к OpenAI на каждый запрос без ограничений, бот просто будет дёргать функцию тысячи раз в минуту. Счёт растёт так же, только уже через твой же сервер.

1. Поставь ограничение частоты запросов (rate limiting) на каждую функцию, которая тратит деньги или отправляет письма: например, не больше 10 запросов в минуту с одного пользователя или IP.
2. На страницах, которые особенно активно долбят (регистрация, вход, форма генерации), добавь капчу или Cloudflare Turnstile.
3. На форме входа ограничь число неудачных попыток. Это закрывает перебор паролей.
4. Не подсказывай, существует ли аккаунт. Сообщение «пользователь с такой почтой не найден» помогает составить список твоих клиентов.

Ограничения бывают и у внешних сервисов: например, Google Sheets API ограничивает чтение 60 запросами в минуту. Полагаться на чужие лимиты нельзя: они защищают сам сервис, про твой кошелёк там никто не думает.

Бонус: проверь зависимости, нейросеть может выдумать библиотеку

Модели иногда предлагают установить пакет, которого не существует. Злоумышленники это знают: они регистрируют пакеты с часто выдуманными названиями и кладут внутрь вредоносный код. Приём называется slopsquatting.

Как защититься:

1. Попроси агента перечислить все зависимости проекта и объяснить, зачем нужна каждая.
2. Найди каждый пакет на npmjs.com или pypi.org руками.
3. Поищи в интернете «название пакета scam» и «название пакета is it safe».
4. Посмотри число скачиваний и живой ли репозиторий на GitHub.
5. Сверь название посимвольно: reqeusts вместо requests выглядит почти так же.

Автоматически это умеет приложение Socket для GitHub, оно предупреждает о подозрительных пакетах в пулл-реквестах.

Промпт для аудита безопасности приложения

Начни с правил. Допиши в CLAUDE.md или AGENTS.md проекта пару строк о безопасности и контекст: что за приложение, где хостится, какие данные хранит. Потом прогоняй аудит после каждой крупной доработки. Промпт ниже рассчитан на Claude Code, Cursor или Codex, запускай его в режиме плана, чтобы агент сначала отчитался, а потом правил.

Ты эксперт по безопасности веб-приложений. Проведи аудит этого проекта перед публичным запуском. Ничего не меняй, пока я не утвержу план.
 
Контекст: [что делает приложение], хостинг [Vercel/Netlify/Cloudflare], база [Supabase/Firebase], хранит [какие данные пользователей], платные API: [OpenAI/Anthropic/Stripe/другие].
 
Проверь по пунктам и по каждому дай вердикт ОК / ДЫРА / НЕ УВЕРЕН с путём к файлу и строкой:
1. Секреты: есть ли ключи API, токены, пароли прямо в коде, в истории git, в клиентском бандле. Есть ли .env в .gitignore.
2. Фронтенд: какие расчёты цен, скидок, ролей и вызовы платных API выполняются в браузере.
3. База: включён ли RLS на каждой таблице, есть ли политики, не разрешают ли они доступ всем авторизованным.
4. Права: где проверяется уровень доступа перед защищёнными действиями, может ли пользователь сам сменить свою роль.
5. Ввод: валидация полей на сервере, вывод пользовательского текста без экранирования, лишние поля в ответах API.
6. Файлы: ограничение типов на сервере, проверка сигнатуры файла.
7. Злоупотребления: ограничение частоты запросов на платные функции, капча на входе и регистрации, защита от перебора паролей, сообщения, раскрывающие существование аккаунта.
8. Зависимости: список пакетов с объяснением, зачем каждый нужен. Отметь незнакомые и подозрительные названия.
 
В конце дай топ-5 дыр по опасности (деньги, утечка данных, захват приложения) и пошаговый план исправления. Не придумывай уязвимости, если не уверен, пиши НЕ УВЕРЕН и что нужно проверить руками.

Агенту стоит помочь внешними сканерами. Semgrep бесплатен, содержит больше 2000 открытых правил и поддерживает 30+ языков. Snyk Code даёт 100 бесплатных сканирований в месяц. GitHub CodeQL встроен в GitHub. Запусти любой из них и скорми отчёт агенту со словами «исправь найденное, каждую правку объясни».

Что делать, если приложение уже атакуют

Увидел в дашборде OpenAI или Anthropic расходы, которых не было? Действуй в три волны.

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

Сводная таблица: 7 проверок за вечер

Чек-лист: что у тебя есть после этой статьи

• Ни одного ключа в коде и в git, все секреты в .env и в переменных хостинга.
• Засвеченные ключи удалены и заменены новыми.
• Жёсткий лимит трат в OpenAI и отдельное пространство с лимитом в Claude Console.
• Автопополнение баланса выключено или осознанно оставлено.
• Платные запросы, цены и роли считаются на сервере.
• RLS включён на каждой таблице, у каждой есть политика по владельцу строки.
• Права проверяются на сервере перед каждым защищённым действием.
• Ввод валидируется, пользовательский текст выводится как текст, файлы проверяются по сигнатуре.
• На платных функциях стоит ограничение частоты, на входе капча и лимит попыток.
• Зависимости проверены руками, отчёт Semgrep или Snyk разобран с агентом.
• Промпт для аудита сохранён и прогоняется после каждой крупной доработки.

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

По материалам: Zapier, исследование RedAccess в публикации Wired от 7 мая 2026, документация OpenAI и Claude Platform.