Двенадцать способов, которыми ломают именно вайбкодеров

01В чём фокус

Крупные банки и IT-компании держат целые отделы безопасности, нанимают пентестеров, платят за найденные уязвимости, и их всё равно регулярно взламывают. Если ресурсов такого масштаба не хватает, какие шансы у сервиса, собранного за выходные в Cursor или Claude Code?

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

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

02Что нужно до старта

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

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

Готовность просить конкретно. Вместо «сделай форму входа» нужно «сделай форму входа с ограничением количества попыток и защитой от перебора паролей». Агент выполняет то, что попросили, а не то, что подразумевалось.

03Ядро

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

вход в аккаунт        брутфорс · credential stuffing
чужие данные            IDOR · неправильные права доступа · SQL-инъекция
деньги                  подделка вебхука · race condition
код и окружение         утечка ключей · непроверенные библиотеки ·
                       XSS · CSRF · чувствительные данные в логах

Ни один из двенадцати способов не требует гениального хакера. Почти всё автоматизировано: сканер гоняют по тысячам сайтов подряд и смотрят, где дверь осталась открытой. Никто не ищет именно вас.

04Двенадцать способов и лекарство от каждого

Брутфорс. Форма входа без ограничения попыток, без капчи и без таймаутов. Сканер перебирает десятки тысяч комбинаций логина и пароля за час. Лекарство: лимит попыток на аккаунт за отрезок времени.

Credential stuffing. Готовые связки логин-пароль из утечек других сервисов. Пользователь завёл почту и пароль на форуме про рыбалку в 2019 году, форум слили в сеть, и теперь эта пара просто подставляется к вашему сервису без перебора вообще, потому что многие используют один пароль на разных сайтах. Лекарство то же самое: лимит попыток плюс уведомление пользователя о подозрительном входе.

Утечка ключей. Ключ от базы данных или токен бота лежит прямо во фронтенде и виден через обычный просмотр страницы в браузере, либо случайно попал в публичный репозиторий на GitHub. Специальные сканеры прочёсывают весь GitHub именно в поисках таких файлов и находят ключ за считанные минуты после публикации. Лекарство: ключи только в переменных окружения, файл с ними не пушится в Git.

IDOR. Проверили, что пользователь залогинен, но не проверили, что заказ номер 4521 принадлежит именно ему. Меняешь номер в адресной строке на 4520 и видишь чужие имя, адрес, последние цифры карты. Лекарство: сервер проверяет владельца записи при каждом запросе, а не только факт авторизации.

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

SQL-инъекция. Один из старейших способов взлома баз данных. Специальная конструкция вместо обычного текста в поле поиска, и если запрос к базе собран склейкой строк, база выполняет её как команду. Лекарство: параметризованные запросы или ORM вместо ручной сборки SQL-строк.

Подделка вебхука. Сервер принимает уведомление об успешной оплате, но не проверяет, что оно действительно пришло от платёжной системы, а не от кого угодно. Такое уведомление легко отправить напрямую, минуя саму оплату, и получить платный доступ бесплатно. Лекарство: проверка подписи или секретного ключа платёжной системы на каждом входящем вебхуке.

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

XSS. В поле отзыва вставляют не текст, а код, и он выполняется у каждого, кто потом открывает страницу, забирая доступ к его аккаунту. Лекарство: выводить пользовательский текст как текст, не как исполняемый HTML.

CSRF. Сайт принимает запросы с любого чужого сайта, потому что так было проще настроить фронтенд. Пользователю присылают ссылку на постороннюю страницу, и пока он на ней с открытым в другой вкладке аккаунтом на вашем сайте, оттуда тихо уходят данные, он для этого даже не нажимает ничего. Лекарство: SameSite-куки и CSRF-токен на важные действия.

Загрузка вредного файла. Загрузку аватарок разрешили, но проверяют только расширение в названии файла. Вредоносный скрипт называют avatar.php, сервер сохраняет его в папку, откуда сам готов исполнить код, и через прямую ссылку на файл открывается доступ ко всему серверу. Лекарство: проверять реальное содержимое файла, а не только имя, и хранить загрузки там, откуда сервер не исполняет код.

Race condition. Несколько одинаковых запросов приходят в одну и ту же миллисекунду, например применить промокод, и сервер не успевает проверить баланс между первым и вторым запросом, применяя оба разом и обнуляя цену. Лекарство: блокировка на уровне записи базы данных при одновременных изменениях одного и того же ресурса.

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

05История: как взломали мой собственный проект

В 2008 году я запускал блог-платформу, на пике выходившую на тысячу постов в день, крупнейшую такую площадку в стране на тот момент. Никакого вайбкодинга тогда ещё не было, я сам только пару лет занимался разработкой.

Меня взломали ровно через способ загрузки вредного файла: вместо аватарки на сервер загрузили PHP-скрипт. Взломщик сам написал мне, что проект взломан и база данных уже скачивается. Я зашёл на сервер и увидел, что файл дампа базы действительно создаётся, но по прямой ссылке из браузера он ещё не открывался, значит скачать его пока не успели. Спросил, как он это провернул, он честно объяснил: залил скрипт под видом аватарки. Оказалось, что он не вымогатель, а просто тренировался на популярном проекте. Пока мы переписывались, я удалил его файл, закрыл дырку в загрузке аватарок и стёр недокачанный дамп. База так и не утекла.

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

06Свой результат за вечер

Четыре шага по чек-листу, от самого дешёвого к самому объёмному.

Шаг первый. Вход и ключи. Проверьте лимит попыток входа, наличие капчи на форме логина, и что ни один ключ или пароль не лежит открыто в коде фронтенда или в публичном репозитории.

Шаг второй. Чужие данные. Пройдитесь по эндпоинтам, которые принимают идентификатор записи (заказ, документ, профиль), и попросите агента проверить, что сервер сверяет владельца, а не только факт авторизации. Отдельно проверьте, что кнопки, спрятанные для обычных пользователей, продублированы проверкой на сервере.

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

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

07Что ты увидишь

Было. Двенадцать разных дыр разбросаны по проекту, часть из них вы даже не подозреваете, потому что код технически работает и вроде бы всё в порядке.

Стало. Чек-лист прогоняется по каждому новому куску кода сразу после того, как он написан, а не откладывается до общего аудита перед запуском.

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

08Чтобы не споткнуться

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

Верить, что раз библиотека установилась без ошибок, значит она настоящая и безопасная. Технически код может прекрасно работать и при этом незаметно отправлять данные на сторонний сервер.

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

09А если…

А если у меня нет оплаты через вебхуки?

Пропустите пункт про подделку вебхука, он актуален только там, где есть внешняя платёжная система с асинхронным уведомлением об оплате.

А если я не могу проверить все двенадцать пунктов сразу?

Начните с блока «чужие данные»: IDOR и неправильные права доступа статистически самые частые и самые дешёвые в реализации атаки среди всех двенадцати.

А если взломщик написал мне и предлагает поговорить?

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

А если мой чек-лист для агента устарел после обновления проекта?

Пересобирайте его вместе с диагностикой: попросите агента проанализировать текущий стек заново, если он существенно изменился с прошлой проверки.

10Зачем на самом деле

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

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

11А дальше

Сервер выполнит любую просьбу гостя. Даже отдать ключи от кассы разбирает механизм части этих же атак подробнее: почему они работают, а не только чем закрываются. IDOR, XSS, CSRF и SQL-инъекция из этого чек-листа разобраны там на уровне «что именно происходит внутри», с готовыми формулировками для агента.

12Источники

OWASP Top 10: https://owasp.org/www-project-top-ten/ Официальный список категорий веб-уязвимостей, где перечислены и IDOR, и SQL-инъекция, и остальные пункты этого чек-листа.

OWASP, File Upload Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html Разбор защиты от загрузки вредоносных файлов под видом обычных.

Stripe, Webhook signatures: https://docs.stripe.com/webhooks#verify-official-libraries Пример того, как платёжная система подписывает вебхуки и как эту подпись проверять на своей стороне.

Snyk: https://snyk.io/ Сервис проверки зависимостей проекта на известные уязвимости и подмену пакетов.

Исходное видео: «12 самых частых способов взломать проект вайб-кодера», youtube.com/watch?v=XDaohGikIrk Первоисточник списка двенадцати способов и личной истории про взлом 2008 года, изложенных в этом гайде своими словами.