Як не злити API-ключі у вайб-кодингу

Чому у вайб-кодингу це трапляється частіше

Під час швидкого прототипування легко попросити AI «просто підключити API» й одразу вставити ключ у код. Проблема в тому, що все, що потрапляє у фронтенд, можна побачити в завантажених файлах або мережевих запитах. А секрет, одного разу збережений у Git, може залишитися в історії навіть після видалення з останньої версії файлу.

Безпечна структура проєкту

Реальні значення тримайте у файлі .env, який не потрапляє до репозиторію. Для команди залишайте лише шаблон .env.example із назвами змінних без секретів.

# .env — локально, не комітимо
OPENAI_API_KEY=справжній_ключ

# .env.example — можна комітити
OPENAI_API_KEY=

# .gitignore
.env
.env.*
!.env.example

На хостингу ключ потрібно додати через розділ Secrets або Environment Variables. Не вставляйте його в HTML, клієнтський JavaScript, публічні конфігураційні файли чи змінні з префіксом, який платформа вбудовує у браузерний код.

Як сформулювати завдання для AI

Замість передачі справжнього ключа дайте асистенту назву змінної та опишіть межу між клієнтом і сервером:

Увімкніть захист GitHub

GitHub Secret Scanning шукає ключі, токени й паролі у всій історії репозиторію. Push protection працює ще раніше: може зупинити відправлення коміту, якщо в ньому знайдено секрет. Для особистих акаунтів захист користувача від витоків у публічні репозиторії ввімкнений за замовчуванням, але попередження не варто обходити без перевірки.

Перед першим публічним push додатково пошукайте у проєкті слова API_KEY, SECRET, TOKEN, PASSWORD і фрагменти форматів ключів ваших сервісів.

Якщо ключ уже засвітився

1. Негайно відкличте ключ у кабінеті сервісу. Видалити рядок із файлу недостатньо.
2. Створіть новий ключ із мінімальними потрібними дозволами та, якщо можливо, строком дії.
3. Замініть значення у змінних середовища на сервері й перевірте, що застосунок працює.
4. Перегляньте використання, рахунки та журнали запитів на незвичну активність.
5. Лише після відкликання вирішуйте, чи потрібно очищати історію Git. Старий ключ усе одно вважайте скомпрометованим.

Що не слід вставляти в AI-чат

• API-ключі, паролі, токени доступу та приватні ключі;
• повні резервні копії робочої бази з даними користувачів;
• production-конфігурації, якщо вони містять адреси, секрети або службові облікові дані;
• чужі персональні, медичні, платіжні чи внутрішні корпоративні дані без дозволу й належного захисту.

Чекліст перед публікацією

• У коді й історії Git немає реальних ключів, паролів або токенів.
• .env та локальні конфігурації додані до .gitignore.
• .env.example містить лише назви змінних і безпечні приклади.
• Секретні API-запити виконуються на сервері, а не у браузері.
• Ключі мають лише необхідні дозволи, ліміти й термін дії, де це доступно.
• У GitHub не проігноровані попередження secret scanning або push protection.
• Перевірені журнали помилок: вони не друкують секрети чи приватні дані.
• Для тестів використані окремі тестові ключі та вигадані дані.
• Налаштовані ліміти витрат або сповіщення про незвичне використання.
• Ви знаєте, де швидко відкликати кожен ключ у разі інциденту.