Як зберігати ключі API в безпеці у вашому застосунку

Щоб зберігати ключі API в безпеці, тримайте їх як секрети або змінні середовища на вашому хостингу, використовуйте лише в серверному коді і ніколи не вставляйте в чат, файли коду, скриншоти чи репозиторій Git. Дайте кожному ключу мінімальні потрібні права, встановіть ліміти витрат у провайдера, а якщо ключ колись витече — змініть його: створіть новий і видаліть старий, а не просто сховайте місце, де він з'явився.

Ключ API — це пароль до сервісу. Ваш ключ OpenAI дозволяє комусь витрачати ваші гроші на AI; секретний ключ Stripe дозволяє видавати повернення коштів; ключ постачальника пошти дозволяє надсилати листи від вашого імені. AI-білдери добре вміють під'єднувати такі ключі, але не завжди уважно стежать, куди вони потрапляють, тож цей посібник про те, як їх зберегти в безпеці і як перевірити.

Публічні ключі та секретні ключі

Не кожен ключ є секретним. Розуміння різниці не дає панікувати через безпечний ключ і не дає ігнорувати небезпечний.

Якщо ви не впевнені, який це тип, перевірте документацію провайдера. У разі сумніву вважайте ключ секретним.

Крок 1: Зберігайте ключі як секрети, а не в коді

Ключі належать до змінних середовища або налаштувань секретів вашого хостингу. Ваш код читає їх за назвою під час роботи (наприклад, process.env.OPENAI_API_KEY), тож значення ніколи не з'являється у ваших файлах. Щоб дізнатися більше, див. що таке змінні середовища і секрети.

Перенеси кожен ключ API з коду в змінні середовища. Перелічи кожен знайдений ключ, файл, у якому він був, і назву змінної, яку ти використав. Не показуй мені значення.

Потім перевірте, що нічого не залишилося:

Пройдися по всьому проєкту, включно з конфігураційними файлами і будь-якими файлами .env, і знайди все, що схоже на ключ API або пароль. Вкажи файл і рядок, але не значення.

Крок 2: Використовуйте секретні ключі лише на сервері

Це найважливіше правило. Усе, що отримує браузер, відвідувач може прочитати: код сторінки і JavaScript-файли видно в інструментах розробника.

Тож якщо застосунку потрібно викликати OpenAI, браузер має викликати ваш сервер, а сервер викликає OpenAI з ключем. Ключ ніколи не покидає сервер.

Функція чату викликає OpenAI напряму з браузера. Перенеси цей виклик на серверний API-маршрут, який читає OPENAI_API_KEY зі змінних середовища. Браузер має викликати лише наш маршрут. Вимагай входу для цього маршруту.

Одна поширена пастка у фреймворках фронтенду: змінні з публічним префіксом — VITE_ у Vite, NEXT_PUBLIC_ у Next.js — навмисно вбудовуються в код браузера. Секретний ключ з таким префіксом відкритий, хоча він і «в змінній середовища».

Крок 3: Перевірте, що нічого не витікає

Не довіряйте тому, що все працює, — перевірте живий сайт:

1. Відкрийте опублікований застосунок у браузері.
2. Відкрийте інструменти розробника, потім вкладку Sources або Network.
3. Шукайте по файлах перші символи кожного секретного ключа (наприклад, sk_ або sk-).
4. Перевірте мережеві запити, які робить застосунок. Запит, що йде прямо з браузера до платного провайдера AI, — тривожний знак.

Якщо ви знайшли секретний ключ, перенесіть його на сервер (крок 2) і змініть (крок 6), адже він уже був публічним.

Крок 4: Обмежте, що може робити кожен ключ

Багато провайдерів дозволяють обмежити ключ:

• Обмежені ключі з областю дії, які можуть робити лише те, що потрібно вашому застосунку. Наприклад, Stripe підтримує обмежені ключі з конкретними дозволами.
• Обмеження за доменом або IP для ключів, які мають бути публічними, як ключі карт.
• Окремі ключі для кожного застосунку і кожного середовища, щоб один витік не відкривав усе, а відкликання одного не ламало інші.
• Тестові ключі під час розробки, а бойові — лише в опублікованому застосунку.

Крок 5: Обмежте шкоду

Навіть добре захищений ключ можна використати неправильно через ваш застосунок — наприклад, коли хтось скриптом викликає вашу AI-функцію тисячі разів.

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

Додай ліміт 30 AI-запитів на користувача на годину для /api/chat. Поверни чітке повідомлення, коли ліміт досягнуто. Відхиляй запити від користувачів, які не увійшли.

Крок 6: Змінюйте ключі, що витекли

Якщо секретний ключ з'явився там, де не мав би, — у повідомленні чату, коміті, скриншоті, зверненні в підтримку, коді браузера, — вважайте його скомпрометованим.

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

Видалення повідомлення в чаті або коміту в Git недостатнє. Історія Git зберігає старі версії, а все публічне могли вже скопіювати.

Типові помилки

• Вставити ключ у промпт. Тепер він є в історії чату. Використовуйте форму для секретів.
• Публічний префікс у секретній змінній. VITE_OPENAI_API_KEY передає ключ кожному відвідувачу.
• Коміт файлу .env. Переконайтеся, що він є в .gitignore до першого пуша.
• Один ключ скрізь. Використовуйте окремі ключі для тестового і бойового режиму та для кожного застосунку.
• Немає ліміту витрат. Витеклий або зловживаний ключ без обмеження може накрутити великий рахунок, перш ніж ви помітите.
• Приховувати замість зміни. Коли ключ був відкритий, виправити ситуацію може тільки новий ключ.
• Ключі на скриншотах. Обріжте або розмийте сторінки налаштувань, перш ніж ділитися ними для допомоги.

Чек-лист

• Кожен ключ збережено як секрет або змінну середовища, а не в коді.
• Файл .env або ключ не закомічено в Git.
• Секретні ключі використовуються лише в серверному коді.
• Жодна секретна змінна не має публічного префікса на кшталт VITE_ або NEXT_PUBLIC_.
• Я шукав у JavaScript живого сайту префікс кожного ключа і нічого не знайшов.
• Ключі обмежені або з обмеженою областю там, де це дозволяє провайдер.
• Тестові і бойові ключі розділені.
• Платні функції вимагають входу і мають обмеження на користувача.
• У кожного платного провайдера є ліміт або сповіщення про витрати.
• Я знаю, як змінити кожен ключ, і будь-який ключ, що колись був відкритий, змінено.

Збереження ключів у Mythex

Mythex тримає ключі поза вашим кодом і чатом двома способами:

• Картка запиту секретів. Коли агенту потрібен ключ, він показує картку в чаті, де ви вводите значення у полях форми, а не в полі повідомлення, і воно зберігається як секрет проєкту. Див. Секрети в чаті.
• Налаштування проєкту → Secrets або /secrets у чаті, щоб додавати або змінювати ключі самостійно. Див. Змінні середовища і секрети.

Після зміни секрету для опублікованого застосунку опублікуйте його знову, щоб живий застосунок його підхопив. Експортовані проєкти не містять секретів, тож додайте їх знову там, де запускаєте код наступного разу. Якщо ключ колись з'явився в чаті, змініть його у провайдера.

Для решти перевірки безпеки перед запуском пройдіть чек-лист безпеки для застосунків, створених з AI. Якщо ви додаєте AI-функції, як використовувати LLM API детальніше розповідає про ключі та витрати.

Запитання