Утёк API-ключ — что делать по шагам
Ключ утёк — счёт растёт. Первые действия занимают минуту, и порядок в них важнее скорости.
2 мин · 8 сентября 2026 г. · безопасность · api-ключи · разработка
Ключ в публичном репозитории находят автоматические сканеры, и обычно быстрее, чем это замечаете вы. Порядок действий важнее скорости: если начать не с того, ущерб продолжит расти, пока вы наводите порядок.
Первое: отзовите ключ
Не меняйте его, не переносите в другое место, не начинайте чистить историю git. Сначала отзовите — это отключает ключ мгновенно и навсегда, и с этого момента ущерб перестаёт расти.
Всё остальное можно делать спокойно.
Частая ошибка — сначала выпустить новый ключ, потом переключить на него сервисы, а старый отозвать «когда всё заработает». В этом промежутке старый ключ продолжает работать у того, кто его нашёл.
Второе: посмотрите, что успели потратить
Откройте историю расходов и сравните с обычной картиной. Смотрите на три вещи: всплеск числа запросов, незнакомые модели и активность в часы, когда вы не работаете.
Если всплеска нет, вам повезло — успели раньше сканеров. Если есть, зафиксируйте объём: он понадобится, если будете обращаться в поддержку.
Третье: выпустите новый и разложите правильно
Новый ключ не должен попасть туда же, откуда утёк старый. Практический минимум:
Ключ живёт в переменных окружения или в менеджере секретов, а не в коде и не в конфиге, который лежит в репозитории.
В .gitignore попадают .env, .env.local и всё, что содержит секреты. Проверьте, что файл уже там, до первого коммита, а не после.
Для каждого сервиса — свой ключ. Утечка одного тогда не требует перевыпуска всех остальных, и по истории видно, какой именно скомпрометирован.
Про чистку истории git
Удалить файл новым коммитом недостаточно: старое содержимое остаётся в истории и доступно любому, кто склонирует репозиторий. Переписать историю можно, но это ломает работу всем, у кого есть локальные копии.
Главное понимать: чистка истории не отменяет утечки. Ключ уже видели, он уже мог быть скопирован. Отзыв — обязателен, чистка истории — гигиена после.
Как не попадать в это
Ключ в скриншоте — второй по частоте способ после git. Прежде чем отправлять снимок терминала в чат или на форум, посмотрите, не видно ли в нём переменных окружения.
Ключ в логах — третий. Если пишете отладочный вывод с заголовками запроса, убедитесь, что Authorization в него не попадает.
И заведите привычку периодически смотреть список активных ключей: те, что вы не можете уверенно связать с конкретным сервисом, лучше отозвать.
zukko
Платите в 25×
меньше
за Claude Code & ChatGPT
Один ключ fetch_* и base URL api.zukko.pro — в Cursor, Claude Code, Codex и любом SDK.