Безопасность API-ключа

API-ключ даёт доступ к моделям и расходованию общего баланса, поэтому обращайтесь с ним как с паролем. Он должен оставаться на доверенной серверной стороне в секрет-хранилище или защищённой переменной окружения.

Безопасный путь запуска

1. Зарегистрируйтесь.
2. Пополните баланс и дождитесь зачисления.
3. Создайте отдельный ключ для проекта в разделе API-ключей.
4. Выберите gpt-5.6-terra как универсальную модель после пополнения или gpt-5.6-luna для экономичного старта.
5. Сверьте model ID и тариф на странице цен, не раскрывая ключ в тестах и логах.

Подробный выпуск ключа описан в гайде как получить GPT API-ключ.

Где хранить ключ

Для локальной серверной разработки передавайте ключ через окружение:

export APIPROVIDER_API_KEY="YOUR_API_KEY"

В CI/CD и production используйте штатное секрет-хранилище платформы. Не помещайте действующий ключ в исходники, публичный .env, Git, браузерный JavaScript, мобильное приложение, скриншот, тикет или чат.

Разделяйте ключи для development, staging и production, а при необходимости — по сервисам. В защищённом реестре храните владельца, назначение и дату пересмотра, но не публикуйте сам секрет.

Серверная схема

1. Клиент отправляет запрос вашему серверу.
2. Сервер проверяет пользователя, формат, права и лимиты.
3. Сервер получает ключ из секрет-хранилища.
4. Сервер вызывает API с Bearer-авторизацией.
5. Клиент получает разрешённый результат, но никогда не получает ключ.

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

Защитите логи и диагностику

До включения HTTP-логирования убедитесь, что маскируются Authorization, секреты конфигурации и чувствительные параметры. Не сохраняйте сырые персональные данные и полный пользовательский контекст «на всякий случай». Для диагностики обычно достаточно времени, статуса, model ID, длительности и безопасного идентификатора задачи.

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

Что делать при утечке

Если ключ оказался в репозитории, логе, чате или скриншоте, считайте его скомпрометированным:

1. немедленно отзовите или замените ключ в кабинете ключей;
2. обновите секрет в сервере, CI/CD и интеграциях;
3. проверьте историю использования и расходы;
4. удалите секрет из публикации и истории по процедуре команды;
5. найдите источник утечки и включите маскирование;
6. проверьте новый ключ минимальным запросом и убедитесь, что старый больше не используется.

Не отправляйте скомпрометированный ключ в поддержку. Передавайте только время, endpoint, код ответа и безопасный ID окружения.

Регулярная проверка

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

Связанные материалы: обработка ошибок без утечки секретов и production-практики.

Частые вопросы

Можно ли хранить ключ во фронтенде?

Нет. Выполняйте API-вызов на сервере, а клиенту возвращайте только разрешённый результат.

Нужно ли скрывать ключ в логах?

Да. Маскируйте весь заголовок Authorization, а не только часть значения.

Достаточно удалить случайный коммит?

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

Проверьте ключи проекта

Откройте раздел API-ключей, удалите неиспользуемые доступы, разделите окружения и убедитесь, что секреты не попадают во фронтенд, Git, логи и сырые пользовательские данные.