Утёк API-ключ — что делать по шагам

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

Первое: отзовите ключ

Не меняйте его, не переносите в другое место, не начинайте чистить историю git. Сначала отзовите — это отключает ключ мгновенно и навсегда, и с этого момента ущерб перестаёт расти.

Всё остальное можно делать спокойно.

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

Второе: посмотрите, что успели потратить

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

Если всплеска нет, вам повезло — успели раньше сканеров. Если есть, зафиксируйте объём: он понадобится, если будете обращаться в поддержку.

Третье: выпустите новый и разложите правильно

Новый ключ не должен попасть туда же, откуда утёк старый. Практический минимум:

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

В .gitignore попадают .env, .env.local и всё, что содержит секреты. Проверьте, что файл уже там, до первого коммита, а не после.

Для каждого сервиса — свой ключ. Утечка одного тогда не требует перевыпуска всех остальных. Учтите только, что история расходов (/v1/usage) общая на аккаунт и фильтра по ключу в ней нет; чтобы видеть расход по каждому ключу, логируйте у себя заголовок X-Zukko-Cost-Micros (он есть у нестриминговых ответов) или задайте ключам дневной и месячный лимит в кабинете.

Про чистку истории git

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

Главное понимать: чистка истории не отменяет утечки. Ключ уже видели, он уже мог быть скопирован. Отзыв — обязателен, чистка истории — гигиена после.

Как не попадать в это

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

Ключ в логах — третий. Если пишете отладочный вывод с заголовками запроса, убедитесь, что Authorization в него не попадает.

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