Где взять API-ключ ChatGPT и как не раскрыть его в коде

По запросу «API-ключ ChatGPT» обычно ищут ключ для обращения к моделям OpenAI из сайта, бота или программы. В официальной терминологии это ключ OpenAI API. Он создается на платформе разработчика, а не в обычном окне переписки ChatGPT.

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

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

Для API нужен аккаунт на платформе OpenAI, проект и настроенный биллинг, если этого требует ваш режим использования. Текущие условия и лимиты проверяйте в кабинете: они меняются и зависят от организации и проекта.

Такое разделение полезно запомнить до разработки. Иначе можно потратить время на поиск ключа в настройках ChatGPT или удивиться отдельным расходам API.

Откройте официальный кабинет API и перейдите в раздел ключей проекта. Создайте новый secret key, укажите понятное имя, например support-bot-dev, и сразу сохраните значение в менеджер секретов или защищенное хранилище. Полный ключ обычно показывается только при создании.

Не называйте ключ просто test или key1. Через несколько месяцев по имени должно быть понятно:

· какому проекту он принадлежит;

· для какой среды создан: development, staging или production;

· какой сервис его использует;

· кого спрашивать при ротации.

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

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

Поэтому схема должна быть такой:

браузер -> ваш сервер -> OpenAI API

Браузер отправляет на ваш сервер только нужные данные. Сервер проверяет пользователя, ограничивает размер и частоту запросов, добавляет API-ключ из защищенного хранилища и обращается к OpenAI. Затем возвращает клиенту только результат, который можно показать.

Неправильная схема выглядит так:

браузер с API-ключом -> OpenAI API

Она раскрывает секрет и лишает вас нормального контроля расходов. CORS или минификация не исправляют архитектурную ошибку.

Официальный quickstart OpenAI предлагает передавать ключ через переменную окружения OPENAI_API_KEY. SDK читает ее при запуске, поэтому секрет не нужно писать в исходном файле.

Для macOS и Linux временная переменная в текущем терминале выглядит так:

Для PowerShell:

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

В проекте часто используют файл .env, который не попадает в Git. Тогда рядом хранится безопасный пример .env.example:

В .gitignore должно быть точное правило для настоящего файла:

Перед первым коммитом выполните git status и убедитесь, что файл с секретом не подготовлен к отправке. Одного правила в .gitignore недостаточно, если файл уже был добавлен в историю Git.

На хостинге используйте раздел Environment Variables или Secrets. Создавайте отдельные значения для development, preview и production, если платформа поддерживает среды. Не копируйте производственный ключ в тестовое окружение без необходимости.

Серверный обработчик должен:

1. читать ключ из окружения;

2. завершать запуск с понятной ошибкой, если ключ не задан;

3. не печатать значение в логах;

4. ограничивать доступ к своему маршруту;

5. проверять входные данные и размер запроса;

6. задавать лимиты времени и обрабатывать ошибки API.

Без этих ограничений секрет формально спрятан, но публичный endpoint можно использовать как бесплатный прокси за ваш счет.

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

Добавь чтение OPENAI_API_KEY из окружения. Не создавай и не изменяй файл с реальным секретом. Добавь пустую переменную в .env.example, проверь .gitignore и остановись перед командами публикации.

После правки ищите не только полную строку ключа. Проверьте git diff, staged diff и файлы конфигурации. Полезно включить автоматическое сканирование секретов в репозитории и защиту push на GitHub.

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

Серверному маршруту нужны собственные меры:

· авторизация пользователя;

· ограничение частоты запросов;

· предел размера входного текста;

· список разрешенных операций;

· таймаут;

· журнал события без полного содержимого и секретов;

· дневной или пользовательский лимит расходов.

API-ключ подтверждает право вашего сервера обратиться к OpenAI. Он не проверяет конечного посетителя сайта. Это разные уровни авторизации.

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

1. отзовите ключ в кабинете OpenAI;

2. создайте новый ключ для нужного сервиса;

3. обновите секрет в среде размещения;

4. перезапустите приложение и проверьте запрос;

5. изучите использование и расходы за период утечки;

6. удалите секрет из текущих файлов и при необходимости очистите историю;

7. добавьте проверку, которая предотвратит повторение.

Сначала отзывайте ключ, потом занимайтесь красивой историей Git. Удаление строки из последнего коммита не делает старый ключ безопасным.

Перед запуском сайта или бота пройдите короткий список:

· в клиентском коде и сетевых ответах нет ключа;

· ключ читается только сервером;

· .env не отслеживается Git;

· тестовая и рабочая среды используют разные секреты;

· публичный маршрут требует авторизацию или имеет жесткий лимит;

· ошибки не печатают заголовок Authorization;

· есть способ быстро отозвать и заменить ключ;

· настроено наблюдение за расходами.

Проверить это лучше на preview-среде с отдельным тестовым ключом. Откройте инструменты разработчика браузера, выполните запрос и изучите весь ответ и заголовки. Затем посмотрите серверные логи.

Один общий ключ для ноутбуков, staging и production мешает расследовать расходы и безопасно отзывать доступ. Создавайте отдельный секрет для каждого приложения и среды. Если платформа поддерживает проекты и service accounts, привязывайте машинный доступ к проекту, а не к личной учетной записи сотрудника.

Составьте небольшой реестр без значений ключей:

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

Иногда разработчик хранит секрет на сервере, но создает endpoint /config, который отдает его браузеру после загрузки страницы. Это все равно раскрытие. Сервер должен сам выполнить запрос к OpenAI и вернуть только нужный результат.

Проверьте JavaScript bundle, HTML, Network tab, source maps и сообщения об ошибках. Убедитесь, что ключ не попадает в аналитические события и отчеты об исключениях. Маскирование части строки в интерфейсе не помогает, если полное значение уже отправлено клиенту.

Для мобильного приложения правило то же: установленное на устройство приложение находится под контролем пользователя. Секрет провайдера хранится за вашим backend.

Ротацию полезно отрепетировать до утечки. Создайте новый ключ, добавьте его в secret storage, перезапустите или переопубликуйте сервис, выполните контрольный запрос и только затем отзовите старый.

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

Для срочной утечки порядок меняется: сначала отзывается скомпрометированный ключ, даже если будет короткий простой. Затем восстанавливается сервис с новым секретом.

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

Настройте редактирование секретов на уровне логгера и платформы наблюдения. Проверьте это намеренной тестовой ошибкой: некоторые SDK печатают объект запроса целиком. Политика «мы не пишем ключ вручную» не защищает от автоматического дампа.

Собирайте количество успешных и ошибочных запросов, лимиты и стоимость на уровне своего сервера. Резкий рост может означать популярность, бесконечный retry, отсутствие rate limit или использование раскрытого ключа. Без раздельных ключей и меток эти причины трудно отличить.

При передаче проекта новому владельцу не отправляйте ключ в мессенджере. Добавьте человека в управление проектом или secret storage с собственной учетной записью. Он создает или получает доступ к секрету штатным способом, проверяет deploy, после чего старый доступ отзывается. Зафиксируйте изменение владельца в реестре ключей.

Сохраните дату этой проверки.

Практический маршрут от серверного endpoint до безопасной публикации разбирается на курсе «Вайб-кодинг: быстрый старт». Ключ при этом должен оставаться за пределами задания, исходников и клиентского приложения.

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