Утечка .env .git или API-ключа: как закрыть доступ и проверить исправление

Что делать прямо сейчас

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

Как подтвердить утечку

Проверьте содержимое ответа, а не только HTTP 200. HTML главной страницы на /.env не доказывает утечку. Учебный файл с вымышленным значением тоже не доказывает действующие полномочия. Назначение реального значения устанавливает владелец через собственную систему управления секретами и провайдера. Не отправляйте ключ на публичный валидатор, в URL поиска или в чат вместе с полным конфигурационным файлом.

Первичные источники: OWASP: Secrets Management · GitHub: устранение утечки

Продолжить: Проверка своего сайта на уязвимости по URL

Почему удаления строки недостаточно

Копии могут остаться в истории Git, старой сборке, CDN, артефактах CI и логах. Удаление строки из текущей ветки не отзывает доступ и не очищает все эти места. Перезапуск приложения тоже не отменяет чужую копию токена. Очистка истории — отдельная операция по процедуре хостинга, которую согласуют с участниками репозитория. Не начинайте с разрушительного переписывания истории, забыв отозвать полномочия.

Как проверить последствия

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

python3 access-fixture.py
# В другом терминале: до исправления — 200 с чужим объектом
curl -H "X-Fixture-User: a" "http://127.0.0.1:8769/documents/doc-b?mode=vulnerable"
# После — 403; doc-a остаётся доступен пользователю a
curl -H "X-Fixture-User: a" "http://127.0.0.1:8769/documents/doc-b?mode=fixed"

Первичные источники: OWASP: Secrets Management · GitHub: устранение утечки

Продолжить: Безопасность Next.js: проверка API Server Actions и секретов

Где появляется секрет

Распространённые источники: публикация рабочего каталога вместо сборки, лишний Docker context, резервный архив в static, NEXT_PUBLIC, вывод CI и диагностический ответ. .gitignore влияет на отслеживание файлов Git, но не запрещает веб-серверу отдавать файл и не очищает уже опубликованный артефакт. В каждом случае ищите точный путь от хранилища секрета до публичного ответа.

Как исправить источник

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

Первичные источники: OWASP: Secrets Management · GitHub: устранение утечки

Продолжить: Безопасность Supabase: как проверить RLS и доступ к данным

Как проверить исправление

Исправление включает два независимых результата. Во-первых, известный публичный путь больше не выдаёт содержимое. Во-вторых, старые полномочия отозваны у источника. Scantelio может повторить внешнюю проверку, но отсутствие находки не подтверждает отзыв ключа. На своём стенде проверьте также известные кэши и артефакты; не скачивайте больше чувствительных данных, чем нужно для подтверждения.

Как предотвратить повторение

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

Продолжить: Как добавить проверки безопасности в CI/CD и GitHub Actions

Воспроизводимые примеры и материалы

Проверено: guides-1 · Python 3.13.0 · PyJWT 2.15.1

Учебные данные — синтетические. Файлы не содержат действующих ключей или клиентской базы. Запускайте примеры только в собственной изолированной тестовой среде.

• launch-checklist.csv — редактируемый шаблон
• Локальный HTTP-стенд: уязвимый и исправленный режимы

Протокол проверки примера: версии, действия и наблюдения

Вопросы и ответы

Автор и источники

Редакция Scantelio: методика и границы проверки. Проверка примера: 2026-11-02.

• OWASP: Secrets Management
• GitHub: устранение утечки