Как проверить безопасность AI-стартапа: пять точек до запуска

Какие пять границ проверить до запуска AI-стартапа?

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

• Карта пяти зон риска с доказательствами из файлов проекта.
• Негативные тесты для входа, доступа к объектам и запросов к базе.
• План действий, если токен уже попал в репозиторий или лог.
• Готовый промпт, который сначала просит Claude провести аудит, а не переписывать проект.

Что даёт эта проверка и чего она не даёт?

Безопасность удобно обсуждать конкретными сценариями. Может ли один пользователь получить чужой отчёт, заменив report_id? Может ли бот сделать тысячу попыток входа? Выполняет ли npm install неизвестный shell-скрипт? Попадает ли ключ модели в клиентский JavaScript?

Начни с карты: браузер, API, база, хранилище файлов, очередь, AI-провайдер, платёжный сервис и панель администратора. Для каждой стрелки запиши, какие данные идут, кто имеет доступ и чем проверяется право. Если сам проект ещё не разделён на такие зоны, сначала пригодится карта ролей AI-сервиса. OWASP ASVS можно использовать как более полный набор технических требований после первого прохода.

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

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

Как защитить вход и восстановление доступа?

Форма входа выглядит маленькой, но за ней находятся пароли, сессии и административные права. Первый тест прост: отправь серию неверных попыток для одной учётной записи и с разных адресов. Сервис должен замедлять или ограничивать повторные попытки, а не бесконечно отвечать с одинаковой скоростью. OWASP отдельно описывает login throttling и осторожное применение временной блокировки.

Проверяй не только /login. В тот же контур входят регистрация, сброс пароля, подтверждение почты, выдача одноразового кода и обновление токена. Ответы не должны помогать перечислять существующие аккаунты. Фраза «если такой адрес есть, мы отправили письмо» раскрывает меньше, чем разные ответы для существующего и неизвестного email.

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

Где не должны жить секреты?

API-ключ модели, пароль базы, секрет проверки webhook и ключ подписи сессии нельзя помещать в исходники, клиентскую сборку, Dockerfile, пример запроса, скриншот или обычный лог. Файл .env удобен локально, но это не делает его безопасным хранилищем для продакшна. В рабочей среде секрет передаётся через систему секретов или защищённые настройки платформы, имеет минимальный scope, только необходимый набор разрешений, и может быть отозван отдельно. Эти принципы совпадают с рекомендациями OWASP по жизненному циклу, минимальным правам, аудиту и ротации секретов.

Проверь три поверхности. В Git ищи текущие файлы и историю. Во frontend bundle, готовых JavaScript-файлах, которые сервер отдаёт браузеру, ищи значения, которые не должен получить посетитель. В логах проверь маскирование заголовков Authorization, cookies, строк подключения и тел запросов. GitHub secret scanning умеет искать известные форматы учётных данных в истории, но не распознает любой внутренний секрет, поэтому автоматический поиск не заменяет ревью.

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

Проверка без раскрытия секрета. В отчёте достаточно написать: «OPENROUTER_API_KEY читается на сервере из окружения». Само значение не нужно вставлять ни в чат, ни в тикет, ни в скриншот.

Чем авторизация отличается от аутентификации?

Наличие валидной сессии ещё не даёт права читать любой объект. Типичная ошибка выглядит так: API принимает /reports/123, находит отчёт с ID 123 и возвращает его любому вошедшему пользователю. Надёжная проверка связывает объект с пользователем, командой или разрешением на доверенном серверном слое. OWASP рекомендует проверять авторизацию на каждом запросе, применять минимальные права и deny by default.

Для каждого endpoint, отдельного адреса и действия API, составь негативный тест. Пользователь A создаёт объект. Пользователь B получает его ID, подставляет в чтение, изменение, удаление, экспорт и ссылку на файл. Каждый запрос должен завершиться отказом без утечки содержимого. Именно подмена идентификатора объекта лежит в основе категории Broken Object Level Authorization из OWASP API Security.

Проверка ресурса = валидная сессия
                    + разрешённое действие
                    + право на конкретный объект
                    + допустимое состояние объекта

Не полагайся на скрытую кнопку в интерфейсе. Пользователь может вызвать API напрямую. Проверка роли, владельца и контекста должна происходить на backend до чтения или изменения данных.

Не забудь соседние действия. Если чтение закрыто, это ещё не значит, что закрыты изменение, удаление, скачивание файла, экспорт списка, просмотр истории и административный поиск. Составь таблицу «роль × действие × тип объекта» и для каждой запрещённой клетки сделай тест. По умолчанию новый маршрут должен запрещать доступ, пока право не добавлено явно.

Как защититься от SQL-инъекций?

Опасная конструкция склеивает запрос и ввод пользователя в одну строку. Безопасная конструкция использует prepared statement или параметры ORM, чтобы база различала код и данные. OWASP называет параметризованные запросы основным способом предотвращения SQL injection и отдельно предупреждает против конкатенации пользовательского ввода.

// Плохо: строка пользователя меняет структуру запроса
"SELECT * FROM reports WHERE owner = '" + userInput + "'"

// Принцип безопасного варианта
query("SELECT * FROM reports WHERE owner = ?", [userInput])

Параметры не всегда подходят для имён колонок, таблиц и направления сортировки. В этих местах пользовательский выбор нужно сопоставить с коротким allowlist из кода. Например, sort=created превращается в заранее заданное имя created_at, а неизвестное значение отклоняется. ORM снимает часть риска, но raw-методы, шаблонные строки и динамические фильтры всё равно нужно искать отдельно.

Как проверять. Сначала найди в коде все места с сырым SQL, конкатенацией строк и форматированием запросов. Затем для каждой формы, фильтра, поиска и сортировки проверь, что пользовательское значение уходит параметром. Не пытайся доказывать защиту одной «магической» строкой атаки: важнее увидеть конструкцию запроса и закрепить её тестом, который ломается при возврате к склейке строк.

Что проверить до npm install?

В npm lifecycle есть preinstall, install, postinstall и prepare. Эти команды могут запускаться во время установки проекта или зависимости. Поэтому незнакомый репозиторий сначала изучают статически, а потом запускают в изолированной среде без реальных секретов.

Первый проход: открой package.json, lock-файл, shell-скрипты, workflow-файлы и зависимости из git, URL или локальных путей. Флаг --ignore-scripts отключает package scripts во время установки, но явный npm run всё равно запускает выбранный скрипт. Это средство первого осмотра, а не универсальная песочница.

Для этой зоны есть отдельный пошаговый маршрут: как проверить GitHub-репозиторий до npm install. Он полезен до того, как код оказался в основном проекте.

Что делать, если секрет утёк?

• Шаг 1. Отзови или ротируй токен. Считай секрет скомпрометированным. Создай новый только после отзыва старого и выдай ему минимальные права. GitHub прямо рекомендует ротацию как первый шаг.
• Шаг 2. Оцени использование. Проверь логи провайдера, неожиданные запросы, расходы, входы и изменения конфигурации. Зафиксируй время возможной экспозиции.
• Шаг 3. Замени секрет во всех потребителях. CI: автоматическая сборка и тесты, продакшн, тестовое окружение, локальные машины и фоновые процессы могут использовать разные копии одного значения.
• Шаг 4. Удали секрет из кода и истории. Обычный новый commit не стирает старое значение из истории. Очистка истории затрагивает клоны, ветки, ответвления репозитория и запросы на слияние, поэтому её нужно планировать отдельно.
• Шаг 5. Закрой причину повторения. Добавь secret scanning (в публичных репозиториях GitHub включает его бесплатно, для приватных нужен платный план), pre-commit проверку, маскирование логов и документированную процедуру ротации.

Какой чек-лист положить в release issue?

Для системного security review расширь список требованиями ASVS, релевантными архитектуре и уровню риска проекта.

Как поручить Claude аудит, а не правки?

Скопируй текст ниже или скачай промпт в Markdown. Если используешь Claude Code, начни с режима plan и ограничь инструменты чтением. В CLI есть отдельные настройки режима разрешений и списков доступных инструментов.

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

Не проси и не выводи реальные ключи, пароли, cookies, токены, строки подключения и персональные данные. Не запускай install-скрипты, миграции, deploy, seed и внешние запросы.

Проверь пять зон: защита входа; хранение и ротация секретов; серверная авторизация на каждый объект; параметризованный SQL; package lifecycle и источники зависимостей.

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

На какие документы опирается статья?

Все ссылки проверены 12 ноября 2026 года. Датозависимые требования, версии документов и настройки сервисов нужно перепроверить перед применением.

• OWASP: Authentication Cheat Sheet Защита входа, login throttling, блокировки и многофакторная аутентификация.
• OWASP: Authorization Cheat Sheet Проверка прав на каждый запрос, least privilege и запрет доступа по умолчанию.
• OWASP: API1:2023 Broken Object Level Authorization Риск доступа к чужому объекту через подмену идентификатора в API.
• OWASP: Secrets Management Cheat Sheet Хранение, выдача, аудит, отзыв и ротация секретов по принципу минимальных прав.
• OWASP: SQL Injection Prevention Cheat Sheet Параметризованные запросы как основной способ отделить данные пользователя от SQL-кода.
• OWASP: Application Security Verification Standard База требований для проверки технических контролей веб-приложения. Версия 5.0.0 от 30 мая 2025 года.
• GitHub Docs: Secret scanning Поиск известных типов секретов в истории и немедленная ротация обнаруженных учётных данных.
• GitHub Docs: Removing sensitive data from a repository Сначала отзыв или ротация секрета, затем очистка истории и координация с владельцами копий.
• npm Docs: Scripts Порядок lifecycle-скриптов preinstall, install, postinstall и prepare.
• npm Docs: Config: ignore-scripts Поведение флага ignore-scripts и границы его защиты.
• Anthropic: Claude Code CLI reference Режим plan (--permission-mode plan) и ограничение набора инструментов Claude Code (--tools, --disallowedTools).