Чек-лист безопасности для приложений, созданных с ИИ: что проверить перед запуском

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

Конструкторы приложений на ИИ хорошо делают так, чтобы функции работали. Но они не осторожны по умолчанию, потому что «осторожность» редко звучит в запросе. Большинство проблем ниже возникает из-за того, о чём никто не просил, поэтому решение обычно в том, чтобы попросить.

Как пользоваться чек-листом

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

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

Если у вас есть только час, выполните все пункты «Обязательно».

1. Аутентификация: кто это?

Аутентификация — это подтверждение того, кто перед вами, обычно через вход в аккаунт. Основы см. в что такое аутентификация, а варианты добавления входа — в как добавить вход в приложение.

• Обязательно: каждая страница, показывающая приватные данные, требует входа. Проверка: выйдите из аккаунта, затем вставьте адрес приватной страницы прямо в браузер.
• Обязательно: каждая конечная точка API, за которой стоят эти страницы, тоже требует входа — а не только страница. Проверка: выйдите из аккаунта, откройте вкладку сети в инструментах разработчика и повторите запрос, который приложение делало, пока вы были в системе.
• Обязательно: пароли хранятся в хешированном виде с помощью медленного алгоритма хеширования, а не в открытом тексте. Рекомендации OWASP по хранению паролей советуют в первую очередь Argon2id, а альтернативы — scrypt, bcrypt или PBKDF2. Спросите: «Как хранятся пароли?»
• Желательно: ссылки для сброса пароля истекают и работают только один раз.
• Желательно: cookie сессии помечены как Secure, HttpOnly и SameSite, а выход из аккаунта завершает сессию на сервере.
• Позже: предложите двухфакторную аутентификацию или вход через провайдера, который её поддерживает.

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

2. Авторизация: что им разрешено делать?

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

• Обязательно: каждое чтение, обновление и удаление проверяет на сервере, что запись принадлежит текущему пользователю (или его команде).
• Обязательно: проверьте это тестом: создайте два аккаунта, A и B. Под A откройте одну из записей A и запомните ID в адресе или сетевом запросе. Войдите под B и запросите тот же ID. B должен получить ошибку, а не данные A.
• Обязательно: страницы администратора и конечные точки API для администраторов проверяют роль пользователя на сервере. Скрытая ссылка на админку — это не защита.
• Обязательно: пользователи не могут изменить свою роль, цену, баланс или поля владельца, отредактировав запрос. Проверка: во вкладке сети посмотрите, что отправляет обновление профиля. Если там есть поля вроде role или isAdmin, попросите ИИ игнорировать их со стороны клиента.
• Желательно: ID в адресах трудно угадать (случайные ID, а не 1, 2, 3). Это не замена проверкам прав, но это ограничивает ущерб, если одна из проверок отсутствует.

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

3. Доступ на уровне строк в базе данных

«Доступ на уровне строк» означает, что каждая строка таблицы (одно бронирование, один счёт) видна только тем пользователям, которым она принадлежит. Есть два распространённых способа обеспечить это:

Оба варианта можно реализовать хорошо. Важно следующее:

• Обязательно: если браузер обращается к базе данных напрямую (некоторые облачные продукты баз данных это позволяют), правила доступа на уровне строк включены для каждой таблицы. Без них любой, у кого есть публичный ключ, может прочитать всю таблицу.
• Обязательно: запросы фильтруют по текущему пользователю или команде, а не по ID, который отправляет браузер.
• Желательно: у общих данных (проекты команды) есть понятное правило, кто входит в команду, и оно применяется в одном месте.

4. Секреты и API-ключи

API-ключ — это пароль для сервиса. Stripe, почтовые сервисы и провайдеры ИИ используют такие ключи. Справочную информацию см. в что такое переменные окружения и секреты.

• Обязательно: ключи хранятся в переменных окружения или секретах проекта и никогда не вписаны в код.
• Обязательно: ключи, которые могут тратить деньги или читать приватные данные, используются только на сервере. Проверка: откройте свой живой сайт, посмотрите исходный код страницы и JavaScript-файлы в инструментах разработчика и поищите начало своего ключа (например, sk_). Его там быть не должно.
• Обязательно: ключи никогда не вставлялись в чат, публичный репозиторий или на скриншот. Если такое было, перевыпустите ключ у провайдера (создайте новый и удалите старый).
• Желательно: используйте ограниченные или ограниченные по области ключи там, где провайдер это предлагает. Stripe, например, рекомендует ограниченные ключи, которые имеют только нужные интеграции права.
• Желательно: тестовые и боевые ключи разделены, а боевое приложение использует боевые ключи только тогда, когда вы готовы.

Некоторые ключи задуманы как публичные: публикуемый ключ Stripe (pk_…) или ключ для карт, ограниченный вашим доменом. Правило касается ключей, которые дают доступ, а не каждой строки, похожей на ключ.

5. Проверка входных данных

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

• Обязательно: проверка выполняется на сервере, а не только в браузере. Проверки в браузере нужны для удобства; их может обойти любой.
• Обязательно: запросы к базе данных используют параметры, а не текст, склеенный из пользовательского ввода (это предотвращает SQL-инъекции). Попросите ИИ подтвердить это.
• Обязательно: текст, который вводят пользователи, выводится как текст, а не выполняется как HTML. Проверка: введите <b>hello</b> как своё имя. Вы должны увидеть теги, а не жирный текст.
• Желательно: при загрузке файлов проверяются тип и размер, а загруженные файлы не отдаются с главного домена приложения как исполняемые страницы.
• Желательно: ошибки, показываемые пользователям, простые («Что-то пошло не так»); подробности ошибок идут только в серверные журналы.
• Желательно: вебхуки от сервисов вроде Stripe проверяют подпись провайдера, прежде чем что-то делать. См. что такое вебхук.

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

6. Лимиты запросов и злоупотребления

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

• Обязательно: вход, регистрация и сброс пароля ограничены по количеству запросов для каждого IP-адреса и для каждого аккаунта.
• Обязательно: всё, что стоит вам денег за каждый вызов — запросы к ИИ-моделям, SMS, email, — имеет лимит на пользователя и требует входа.
• Желательно: публичные формы (контакты, лист ожидания) защищены от спама: лимит запросов, скрытое поле-ловушка (honeypot) или CAPTCHA.
• Желательно: установите лимиты расходов или уведомления у платных провайдеров, чтобы ошибка или злоумышленник не могли выставить безграничный счёт.

7. Зависимости

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

• Желательно: попросите ИИ проверить известные уязвимости (для проектов на JavaScript — npm audit или аналог для вашего менеджера пакетов) и обновить затронутые пакеты.
• Желательно: удалите пакеты, которые приложение больше не использует.
• Желательно: будьте осторожны с пакетами, у которых очень мало пользователей, или с названиями, похожими на опечатки популярных.
• Позже: проверяйте раз в месяц или два либо включите автоматические оповещения, если код на GitHub.

8. Резервные копии и восстановление

Безопасность включает возможность восстановиться после ошибок — ваших, ИИ или злоумышленника.

• Обязательно: знайте, где находятся ваши данные и есть ли их резервные копии. Не предполагайте — проверьте в документации хостинга.
• Желательно: делайте собственный периодический экспорт важных данных (например, функцию экспорта в CSV или дамп базы данных) и храните его отдельно.
• Желательно: храните код в системе контроля версий, чтобы можно было вернуть любую версию.
• Желательно: необратимые действия (удаление аккаунта, удаление проекта) запрашивают подтверждение, и стоит рассмотреть «мягкое удаление», которое можно отменить в течение некоторого времени.
• Позже: реально протестируйте восстановление хотя бы раз. Резервная копия, которую ни разу не восстанавливали, — это надежда, а не план.

9. Перед запуском

• Обязательно: живой сайт использует HTTPS везде.
• Обязательно: тестовые данные, тестовые аккаунты и отладочные страницы из разработки удалены.
• Желательно: в политике конфиденциальности сказано, какие данные вы собираете и зачем, — во многих странах это обязательно, если вы собираете персональные данные. Не заявляйте сертификаты (SOC 2, HIPAA), которых у вас нет.
• Желательно: есть способ связаться с вами по вопросам безопасности, и вы знаете, как быстро перевыпустить любой ключ.

Общий предзапусковой проверке, не ограниченной безопасностью, см. как вывести прототип ИИ в продакшн.

Когда нужна профессиональная проверка

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

Безопасность при создании приложения на Mythex

В Mythex нет панели проверки безопасности, поэтому процесс — это чек-лист выше. Некоторые вещи помогают:

• Секреты проекта. Храните ключи в настройках проекта → Секреты или через карточку с секретами, которую агент показывает в чате, чтобы они не попадали в код и сообщения. После изменения секрета для живого приложения опубликуйте его снова.
• Режимы «План» и «Вопрос». Попросите агента проверить права без редактирования: «В режиме Ask перечисли каждый маршрут API и какую проверку прав он делает».
• /test заставляет агента кликать по вашему превью как пользователь — полезно для теста с двумя аккаунтами из раздела 2.
• Контрольные точки позволяют откатить изменение, которое что-то сломало.

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

Вопросы