Как да пазите 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 например поддържа ограничени ключове със specific права.
• Ограничения по домейн или 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 в чата, за да добавяте или променяте ключове сами. Вижте Променливи на средата и тайни.

След промяна на тайна за публикувано приложение публикувайте отново, за да я вземе работещото приложение. Експортираните проекти не включват тайните, затова ги добавете отново там, където изпълнявате кода следващия път. Ако някой ключ някога се появи в чата, подновете го при доставчика.

За останалата част от проверката за сигурност преди пускане минете през контролния списък за сигурност на приложения, изградени с AI. Ако добавяте AI функции, как да използвате LLM API разглежда ключовете и разходите по-задълбочено.

Въпроси