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

Что проверить в первую очередь

Начните с пяти действий: убедитесь, что без входа нет приватного ответа; проверьте чужой объект; исключите повышение роли через запрос; проверьте отсутствие опубликованной конфигурации; свяжите зависимости с развёрнутым релизом. После исправления повторите исходный запрос и обычное разрешённое действие. Зелёный экран после входа проверяет удобный путь пользователя, но ничего не говорит о запрете обходного пути. Для MVP с платежами или чувствительными данными глубину проверки выбирают по последствиям ошибки, а не по количеству страниц.

Какие данные и действия защищает ваш продукт

Запишите три наиболее ценные сущности: например, документ, счёт и приглашение в организацию. Для каждой укажите владельца, участников с общим доступом, разрешённые действия и все маршруты получения. Отдельно перечислите файлы, фоновые экспорты, внешние платные API и восстановление доступа. Мобильный бэкенд, CRM или магазин проверяется через подключённые HTTP-компоненты; название отрасли не расширяет покрытие. Не включайте реальные данные клиентов в тестовый набор.

Первичные источники: OWASP: объектная авторизация · OWASP: правила доступа

Продолжить: Проверка своего сайта на уязвимости по URL

Чек лист перед первыми пользователями

Скачайте редактируемый чек-лист ниже. В каждой строке нужны наблюдение и ответственный, а не только галочка. Например, «вход проверен» замените на «запрос без сессии не возвращает приватный маркер». Укажите сборку и окружение, чтобы не переносить результат staging на production автоматически. Резервное копирование, восстановление данных и лимиты расходов внешнего провайдера проверяет владелец: Scantelio не выполняет эти административные операции за него.

Проверка двумя аккаунтами

Создайте A в организации X и B в Y. Владелец A читает doc-a, владелец B — doc-b. Затем A запрашивает известный doc-b: приватного маркера B в ответе быть не должно. В учебном стенде до исправления маркер возвращается; после проверки владельца — отказ, при этом B продолжает читать свой документ. Не перебирайте случайные идентификаторы. UUID и скрытая кнопка уменьшают видимость ссылки, но не задают серверные права.

python3 access-fixture.py
# В другом терминале: до исправления — 200 с чужим объектом
curl -H "X-Fixture-User: a" "http://127.0.0.1:8769/documents/doc-b?mode=vulnerable"
# После — 403; doc-a остаётся доступен пользователю a
curl -H "X-Fixture-User: a" "http://127.0.0.1:8769/documents/doc-b?mode=fixed"

Первичные источники: OWASP: объектная авторизация · OWASP: правила доступа

Продолжить: IDOR и BOLA: как проверить доступ к чужим данным в своём API

Как проверять проекты из Cursor Claude Code Lovable и Bolt

Для Cursor, Claude Code, Lovable и Bolt последовательность одинаковая: проверяется результат работы приложения и его настройка. Не нужно искать особую уязвимость «кода от конкретного ИИ». Для Supabase проверьте клиентские роли и RLS; для Next.js — серверные операции и данные, попавшие в браузер. Эти руководства не означают прямой интеграции Scantelio с IDE или конструктором. Изменённые ими файлы всё равно проходят обычный review и тесты вашего проекта.

Что проверяет код и что проверяет работающий сервис

SAST рассматривает исходники, SCA — состав и версии компонентов, DAST — поведение работающего сервиса. Внешняя проверка Scantelio не получает весь репозиторий из URL. Инвентарь зависимостей загружается отдельно, а сценарии доступа требуют аккаунтов и объектов. У каждого вида проверки есть слепые зоны: безопасный фрагмент кода не доказывает безопасную настройку сервера, а отсутствие внешней находки не доказывает отсутствие ошибки в непосещённой операции.

Первичные источники: OWASP: объектная авторизация · OWASP: правила доступа

Продолжить: Безопасность Supabase: как проверить RLS и доступ к данным

Как передать исправление ИИ и проверить результат

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

Как повторять проверки после запуска

После изменения ролей, хранения файлов или деплоя повторите нужные сценарии. Сохраните связь «находка — изменение — ретест — сборка». Включайте расписание и CI по доступному тарифу, актуализируйте инвентарь зависимостей после релиза. Если истекла тестовая сессия или не хватило бюджета, сначала восстановите возможность проверки: частичный запуск не заменяет подтверждение исправления. Отсутствие находок полезно только вместе с известным выполненным покрытием.

Продолжить: Проверка своего сайта на уязвимости по URL

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

Продолжить: IDOR и BOLA: как проверить доступ к чужим данным в своём API

Продолжить: Безопасность Supabase: как проверить RLS и доступ к данным

Продолжить: Безопасность Next.js: проверка API Server Actions и секретов

Продолжить: Утечка .env .git или API-ключа: как закрыть доступ и проверить исправление

Продолжить: Безопасность JWT: как проверить токены и отзыв доступа в своём API

Продолжить: Мониторинг CVE и зависимостей вашего приложения

Продолжить: Как добавить проверки безопасности в CI/CD и GitHub Actions

Воспроизводимые примеры и материалы

Проверено: guides-1 · Python 3.13.0 · PyJWT 2.15.1

Учебные данные — синтетические. Файлы не содержат действующих ключей или клиентской базы. Запускайте примеры только в собственной изолированной тестовой среде.

• launch-checklist.csv — редактируемый шаблон
• Локальный HTTP-стенд: уязвимый и исправленный режимы

Протокол проверки примера: версии, действия и наблюдения

Вопросы и ответы

Автор и источники

Редакция Scantelio: методика и границы проверки. Проверка примера: 2026-11-02.

• OWASP: объектная авторизация
• OWASP: правила доступа