Genius-bot · 11 минут чтения
Если вы подключаете api нейросети к своему приложению, главный секрет безопасности находится не в запросе к API, а в том, где лежит ключ авторизации. Один случайно закоммиченный токен может дать постороннему доступ к вашему балансу и позволить отправлять запросы от вашего имени. Ключ выдаётся в разделе API после входа и показывается один раз, поэтому обращаться с ним нужно как с паролем.
На практике проблемы обычно возникают не из-за сложной атаки, а из-за обычного рабочего процесса: ключ оставили в файле с кодом, вставили в JavaScript, отправили коллеге в чат или забыли удалить из тестового проекта. Ниже разберём конкретно, где такие значения оказываются доступными посторонним, почему браузер не подходит для хранения секрета и как сократить ущерб, если утечка уже произошла.
Три места, откуда ключи утекают чаще всего
Первое место — исходный код. Самый простой пример выглядит безобидно: разработчик записывает токен прямо в Python-файл, чтобы быстро проверить запрос, а затем добавляет файл в Git. Даже если секрет позже удалить из текущей версии, он может остаться в истории коммитов. Поэтому удаление строки из последнего коммита не стоит считать исправлением утечки.
API_KEY = "ваш-реальный-ключ"
Для локального теста безопаснее вынести значение в переменную окружения. Сам код тогда содержит только имя переменной, а не сам секрет.
import os
import requests
API_KEY = os.environ["GENIUS_API_KEY"]
response = requests.post(
"https://genius-bot.ru/wp-json/genius/v1/generate",
headers={
"Authorization": f"Bearer {API_KEY}"
},
json={
"service": "image",
"prompt": "Кот в красном шарфе"
},
)
print(response.status_code)
print(response.text)
Второе место — файлы конфигурации. Например, разработчик может хранить настройки в .env, JSON или YAML-файле и случайно отправить его в репозиторий. Сам по себе формат файла не делает ключ защищённым: если файл попал в общедоступное место, значение внутри него следует считать скомпрометированным.
Третье место — переписка и логи. Ключ могут вставить в сообщение с просьбой «проверить, работает ли API», сохранить полный HTTP-запрос в журнале или вывести заголовки в консоль при отладке. Особенно опасны логи CI/CD и системы сбора ошибок, куда иногда автоматически попадают параметры запроса.
Есть простой практический принцип: ключ должен присутствовать только там, где он действительно нужен для выполнения серверного запроса. Чем меньше копий секрета существует, тем меньше мест приходится контролировать.
Почему ключ не должен попадать в код фронтенда
Браузер пользователя нельзя считать доверенной средой для хранения секретного API-ключа. Всё, что необходимо браузеру для отправки запроса напрямую, потенциально может увидеть пользователь: JavaScript-код, сетевые запросы, исходные карты, инструменты разработчика и другие данные страницы доступны на клиентской стороне.
Например, такой код технически может отправить запрос, но размещать в нём настоящий секретный ключ нельзя:
const API_KEY = "ваш-реальный-ключ";
fetch("https://genius-bot.ru/wp-json/genius/v1/generate", {
method: "POST",
headers: {
"Authorization": `Bearer ${API_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
service: "image",
prompt: "Город ночью под дождём"
})
});
Проблема здесь не в синтаксисе запроса. Заголовок Authorization: Bearer <ключ> предназначен для авторизации запроса, а сам ключ должен оставаться на серверной стороне. Если поместить его во фронтенд, посетитель страницы сможет получить значение и использовать его самостоятельно.
Правильная схема состоит из двух запросов. Браузер обращается к вашему серверу, сервер проверяет входные данные и уже затем выполняет запрос к API с секретом. Клиент получает результат операции, но не получает ключ.
Это особенно важно для приложений, где пользователь может самостоятельно задавать текст запроса, загружать файлы или запускать генерации. В таком сценарии сервер должен контролировать, какие параметры разрешены, а ключ должен находиться только в серверной конфигурации.
При загрузке файлов ситуация аналогична. API предусматривает отдельный маршрут POST /uploads, который используется для загрузки файла и получения ссылки. Сам секрет при этом не должен передаваться в HTML или JavaScript страницы.
Для серверного Python-кода запрос выглядит, например, так:
import os
import requests
key = os.environ["GENIUS_API_KEY"]
r = requests.post(
"https://genius-bot.ru/wp-json/genius/v1/generate",
headers={"Authorization": f"Bearer {key}"},
json={
"service": "image",
"prompt": "Минималистичный интерьер с большим окном"
},
timeout=60
)
r.raise_for_status()
print(r.json())
При таком разделении секрет остаётся на сервере, а браузер работает с вашим собственным endpoint. Это не отменяет необходимость защищать сервер: переменные окружения, конфигурация и логи также должны иметь ограниченный доступ.
Отдельный ключ на каждый проект и зачем это нужно
Если несколько приложений используют один и тот же ключ, авария в одном проекте автоматически становится проблемой для остальных. Например, один ключ используется одновременно сайтом, внутренним ботом и тестовым скриптом. После утечки невозможно просто отключить доступ одного приложения, не затронув два других.
Практичнее выпускать отдельный ключ для каждого независимого проекта или среды. Тогда ключ проекта A не используется проектом B, а тестовая интеграция не должна делить секрет с рабочим приложением.
У такого подхода есть ещё одно преимущество: проще найти источник проблемы. Если расход неожиданно появился на одном ключе, вы хотя бы знаете, к какому приложению он относится. При одном общем ключе сначала приходится разбираться, какая из систем отправляет подозрительные запросы.
Отдельные ключи особенно полезны при передаче проекта между разработчиками. Не нужно распространять один универсальный секрет по нескольким компьютерам и окружениям. Каждый проект получает собственную конфигурацию, а доступ к ней можно ограничить на уровне инфраструктуры.
| Схема | Что происходит при утечке | Диагностика расходов |
|---|---|---|
| Один ключ для всех проектов | Под угрозой оказываются все приложения, использующие ключ | Сложно определить источник запросов |
| Отдельный ключ на проект | Проблема ограничивается конкретным проектом | Проще связать расход с приложением |
| Отдельные ключи для production и тестов | Утечка тестового ключа не затрагивает рабочую конфигурацию | Расходы разделены по средам |
Само наличие нескольких ключей не заменяет контроль доступа. Не стоит хранить все секреты в одном доступном каждому файле или пересылать их вместе с исходным кодом. Смысл разделения в том, чтобы уменьшить область потенциального ущерба.
Что делать в первые минуты после утечки
Если ключ оказался в публичном репозитории, сообщении или клиентском коде, исходить нужно из того, что его уже увидел посторонний. Не имеет значения, заметили ли вы проблему через две минуты или через два часа. Первый шаг — прекратить использование скомпрометированного ключа и выпустить новый.
Особенно важно не ограничиваться удалением строки из файла. Если ключ попал в Git-репозиторий, нужно проверить историю коммитов и другие места, куда автоматически копируется содержимое проекта. Скомпрометированное значение после этого нельзя возвращать в рабочую конфигурацию.
Следующий шаг — проверить баланс и активность проекта. У сервиса есть маршрут GET /balance для получения остатка. Если приложение ведёт собственный журнал операций, сопоставьте время появления необычного расхода с событиями в логах.
При необходимости проверьте также код фронтенда, собранные JavaScript-файлы, CI/CD-конфигурацию, переменные окружения на сервере и документацию проекта. Частая ошибка — заменить ключ в одном месте и оставить старое значение в другом.
После замены ключа полезно пройти обратный путь: найти все места, где старый секрет мог сохраниться. Это могут быть резервные копии, тестовые конфигурации, контейнеры, локальные файлы разработчиков и артефакты сборки. Чем дольше скомпрометированный ключ существует в инфраструктуре, тем выше вероятность повторного использования.
Отдельно стоит учитывать, что ключ показывается один раз при выдаче. Поэтому новый ключ нужно сразу сохранить в защищённом месте. Если значение потеряно, не следует рассчитывать на возможность снова увидеть тот же секрет в интерфейсе.
Лимиты и баланс как страховка от чужих запросов
Безопасность ключа — это первая линия защиты, но она не должна быть единственной. У API есть ограничение частоты: не более 60 запросов в минуту на один ключ. Это ограничивает интенсивность запросов с конкретного ключа, но не заменяет его своевременную замену после утечки.
Есть и финансовая граница в виде баланса. Оплата производится за запуск операции, без абонентской платы и минимального платежа. При выпуске первого ключа на баланс начисляется 50 ₽ для пробы, поэтому даже тестовое окружение имеет конкретный денежный остаток, который стоит учитывать.
Цены зависят от операции. Например, запуск генерации изображения стоит 9 ₽, изменение изображения по описанию — 35 ₽, а генерация видео по описанию — 119 ₽. Поэтому одинаковое количество запросов к разным операциям может создавать совершенно разные расходы.
| Операция | Цена за запуск |
|---|---|
| Картинка по описанию (image) | 9 ₽ |
| Оживить фото (photo-video) | 25 ₽ |
| Изменить фото по описанию (image-edit) | 35 ₽ |
| Увеличить качество фото (upscale) | 50 ₽ |
| Видео по описанию (video) | 119 ₽ |
| Создать музыку (music) | 59 ₽ |
| Расшифровка записи (stt) | 10 ₽ |
| Говорящий аватар (avatar) | 120 ₽ |
| Озвучка текста (tts) | 18 ₽ за 1000 знаков |
Из этого следует практический вывод: не стоит оценивать риск только количеством запросов. Десятки дешёвых запусков и несколько дорогих операций имеют разный финансовый эффект. Если приложение позволяет пользователю выбирать операцию, серверу имеет смысл явно учитывать разрешённые сценарии и ожидаемый расход.
Для контроля состояния баланса можно использовать отдельный запрос:
curl https://genius-bot.ru/wp-json/genius/v1/balance \
-H "Authorization: Bearer $GENIUS_API_KEY"
Для более сложных интеграций API предоставляет также GET /services, где можно получить список операций и цен. Это удобно для внутренней проверки конфигурации: если приложение запускает определённую операцию, цена должна быть известна до того, как вы начнёте считать допустимый расход.
Работа с задачами тоже влияет на архитектуру контроля. После POST /generate состояние и результат можно получать через GET /tasks/{id}. Для асинхронного сценария предусмотрен необязательный callback_url: когда задача готова, на указанный адрес приходит POST. Это позволяет не держать секрет на стороне клиента ради проверки статуса.
Для чата доступны совместимые с OpenAI маршруты POST /chat/completions и GET /models. В клиентской библиотеке достаточно изменить base_url и ключ, а тариф составляет 40 ₽ за миллион токенов запроса и 400 ₽ за миллион токенов ответа. При этом секрет всё равно должен оставаться на сервере, независимо от используемой операции.
Проверка перед выкладкой: короткий список
Перед публикацией приложения полезно сделать отдельную проверку безопасности API-ключа. Она занимает несколько минут и позволяет найти ошибки, которые легко пропустить при обычном тестировании функциональности.
- Ключ не прописан непосредственно в исходном коде.
- Файл с секретами не попадает в репозиторий.
- Скомпрометированные значения удалены не только из текущей версии, но и проверены в истории репозитория.
- Ключ не передаётся в HTML, JavaScript или другой код, который выполняется в браузере.
- Секрет не выводится в консоль и логи вместе с заголовком
Authorization. - Для разных проектов и сред используются разные ключи.
- После утечки старый ключ не продолжает использоваться в резервной конфигурации.
- Приложение знает, какие операции API ему действительно нужны.
- Баланс можно проверить через
GET /balance. - Частота запросов учитывает ограничение 60 запросов в минуту на ключ.
Перед первым production-запуском полезно выполнить поиск по репозиторию по нескольким признакам: имени переменной, префиксу ключа, строке Authorization и адресам конфигурации. Такой поиск не гарантирует обнаружение секрета, но помогает заметить очевидные случаи, когда разработчик оставил значение в тестовом файле.
Ещё один рабочий сценарий — намеренно проверить архитектуру через браузер. Откройте инструменты разработчика и посмотрите сетевые запросы приложения. Если настоящий API-ключ виден в запросе из браузера, значит секрет оказался на клиентской стороне и схему нужно изменить.
Полезно также разделять понятия «ключ скрыт» и «ключ защищён». Переименование переменной, обфускация JavaScript или помещение токена в строку с необычным названием не превращают его в секрет. Если значение необходимо браузеру для выполнения запроса, пользователь потенциально может его извлечь.
Частые вопросы
Где получить ключ API?
Ключ выдаётся после входа в разделе API сервиса. При выпуске он показывается один раз, поэтому значение следует сразу сохранить в защищённой конфигурации, а не в исходном коде.
Можно ли хранить ключ API в JavaScript на сайте?
Нет, если это секретный ключ для авторизации серверных запросов. Код и сетевые запросы браузера доступны пользователю, поэтому ключ следует хранить на сервере и выполнять обращение к API через серверную часть приложения.
Что делать, если произошла утечка API ключа?
Скомпрометированный ключ нужно перестать использовать, заменить новым и проверить места, где старое значение могло сохраниться. После этого стоит проверить баланс и журналы приложения, чтобы определить, не было ли неизвестных запусков.
Зачем выпускать отдельный ключ для каждого проекта?
Это разделяет проекты между собой. Если один ключ становится доступен постороннему, проблема не распространяется автоматически на приложения, которые используют другие ключи. Кроме того, так проще сопоставлять расход с конкретным проектом.
Есть ли ограничение на количество запросов?
На один ключ разрешено не более 60 запросов в минуту. Это ограничение по частоте не отменяет необходимость хранить ключ в закрытой серверной среде и заменять его после утечки.
Где проверить остаток средств?
Для этого предусмотрен маршрут GET /balance. Перед публикацией проекта полезно также учитывать стоимость конкретных операций и разделять ключи между тестовой и рабочей средой.
Правильное хранение ключа API сводится не к одному приёму, а к нескольким простым ограничениям: секрет находится на сервере, не попадает в репозиторий и браузер, проекты используют отдельные ключи, а после утечки старое значение перестаёт использоваться. Документация и управление ключами доступны в разделе управления API.
