Застосунок від ШІ працює, а ключі вже витекли
Ключ API — це рядок символів, який заміняє пароль, коли один сервіс звертається до іншого. API означає прикладний програмний інтерфейс: через нього застосунок просить у сервісу дані, оплату чи відповідь штучного інтелекту (ШІ). Правило одне: ключ не має лежати в коді, який ви копіюєте з чату, публікуєте на GitHub або віддаєте браузеру.
Порушують його частіше, ніж здається. У жовтні 2025 року компанія Escape.tech перевірила близько 5 600 загальнодоступних застосунків, створених у сервісах для вайбкодингу, тобто генерації програм за текстовим описом. Дослідники знайшли понад 2 000 уразливостей із високим впливом і понад 400 відкритих секретів, серед яких ключі API й токени доступу.
Звідки беруться відкриті секрети
Мовна модель виконує поставлене завдання й не відповідає за захищеність усього проєкту. Їй потрібно, щоб приклад запрацював із першого запуску, тому ключ нерідко з'являється просто в рядку коду. Людина, яка не пише код щодня, цього не помічає: сторінка відкривається, кнопки натискаються, дані приходять. Усе виглядає справним.
Проблема виходить за межі навчальних проєктів. У травні 2026 року ізраїльська компанія RedAccess повідомила про приблизно 380 000 загальнодоступних вебресурсів, створених за допомогою Lovable, Base44 і Replit або розміщених на Netlify. Близько 5 000 із них мали корпоративне призначення, а частина віддавала внутрішні дані будь-кому, хто знав адресу сторінки.
Застосунок, який працює, ще не доводить, що він безпечний. Це дві різні перевірки, і друга не виконується сама собою.
Де саме ховається ключ
Секрет зазвичай ховається тут:
- у самому коді, в рядку зі змінною;
- у фронтенді, який видно кожному відвідувачу;
- у файлі .env, що потрапив до репозиторію;
- у конфігурації, вставленій у чат разом із ключем.
Фронтенд заслуговує окремої уваги. Усе, що потрапило в код для браузера, бачить кожен, хто відкрив інструменти розробника. Вставляючи конфігурацію в чат, ви передаєте ключ стороннім серверам, тож замініть реальні значення заглушками на кшталт YOUR_API_KEY.
Що зробити до публікації
Перед тим як опублікувати застосунок, пройдіть такий порядок дій:
- Знайдіть у проєкті всі рядки, схожі на ключі, токени й паролі.
- Перенесіть їх у змінні середовища, а файл .env додайте до виключень Git.
- Переконайтеся, що жоден ключ не потрапляє в код для браузера.
- Обмежте права кожного ключа й задайте ліміт витрат у кабінеті сервісу.
- Увімкніть на GitHub сканування секретів і захист від випадкового пушу.
Запити до платних сервісів краще пускати через власний сервер: браузер звертається до нього, а сервер додає ключ. Ліміт витрат потрібен тому, що чужий скрипт із вашим ключем здатен швидко спустошити бюджет. Файл .env тримає значення поруч із проєктом, але в репозиторій потрапляти не повинен. Для цього достатньо двох рядків у файлі .gitignore:
.env
.env.*Якщо над проєктом працює кілька людей, додайте файл .env.example із порожніми значеннями. Колеги побачать, які змінні потрібні, і не питатимуть ключі в месенджері.
Порівняння способів зберігання ключів
Рівень захисту залежить від того, де лежить секрет. Таблиця допоможе вибрати спосіб під ваше завдання.
| Спосіб | Ризик | Де доречний |
|---|---|---|
| У коді | Найвищий | Ніде |
| Файл .env | Середній | Локальна робота |
| Змінні хостингу | Нижчий | Малі проєкти |
| Сховище секретів | Найнижчий | Команди й бізнес |
Для невеликого проєкту вистачає змінних середовища на хостингу. Команді з кількома розробниками та середовищами краще підійде окреме сховище секретів, яке видає ключі за запитом і веде журнал доступу.
Якщо ключ уже на GitHub
Офіційна документація GitHub радить спершу відкликати ключ у його провайдера. Новий коміт без цього рядка, видалення файлу й навіть перестворення репозиторію не зупиняють того, хто вже скопіював значення. Дані подано станом на 4 жовтня 2026 року.
Якщо боїтеся зупинки сервісу, зробіть інакше: створіть новий ключ із тими самими правами, переведіть на нього застосунок і лише тоді відкличте старий. Для підтримуваних типів секретів у публічних репозиторіях GitHub сам повідомляє провайдера, і той може одразу анулювати ключ. Очищення історії комітів — другий крок, а не перший.
Чому видалення файлу не допомагає
Git зберігає кожну версію файлів в історії. Навіть після видалення рядка старий коміт лишається доступним, а клони й форки репозиторію могли вже зберегти копію. Тому будь-який ключ, що колись потрапив у публічний репозиторій, вважайте відомим стороннім.
Куди рухається ситуація
Прогноз: найближчими місяцями перевірка секретів, імовірно, стане для платформ і репозиторіїв типовою опцією, а не додатковою. Підстава — GitHub уже за замовчуванням блокує пуш відомих секретів до публічних репозиторіїв, а звіти про відкриті застосунки з'являються регулярно. Перевірити цей прогноз можна навесні 2027 року за новими звітами дослідників і налаштуваннями платформ.
Для проєктів із персональними даними клієнтів чи платежами варто залучити фахівця з безпеки: цей текст дає базові правила, а не повний аудит.
Відкритий ключ непомітний, доки його не знайде хтось сторонній, і тоді рахунок за чужі запити отримує власник. Перед кожною публікацією витратьте десять хвилин на пошук секретів у проєкті, і більшість історій із витоками вас обійде. Напишіть у коментарях, який спосіб зберігання ключів ви використовуєте у своїх проєктах.
Похожие публикации: