Како да ги чувате 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: Менувајте клучеви што протекуваат

Ако тајниот клуч се појави каде што не треба — во порака во чет, commit, снимка од екранот, барање за поддршка, код во прелистувачот — претпоставете дека е компромитиран.

1. Создајте нов клуч кај провајдерот.
2. Ажурирајте ја тајната во поставките на вашата апликација.
3. Повторно распоредете или објавете повторно за живата апликација да го користи новиот клуч.
4. Избришете го стариот клуч кај провајдерот.
5. Проверете ги дневниците на употреба кај провајдерот за активност што не ја препознавате.

Бришењето на пораката во чет или на Git commit-от не е доволно. Историјата на Git ги чува стари верзии, а секое што било јавно веќе можеби е копирано.

Чести грешки

• Залепување клуч во упатот. Сега е во историјата на четот. Наместо тоа користете формулар за тајни.
• Јавен префикс на тајна променлива. VITE_OPENAI_API_KEY го испраќа клучот до секој посетител.
• Закачување .env датотека. Погрижете се дека е во .gitignore пред првиот push.
• Еден клуч насекаде. Користете посебни клучеви за тестирање и за живо, и за секоја апликација.
• Нема лимит на трошење. Протеен или злоупотребен клуч без граница може да направи голема сметка пред да забележите.
• Скривање наместо менување. Откако клуч бил изложен, само нов клуч го поправа проблемот.
• Клучеви во снимки од екранот. Исечете или замаглете ги страниците со поставки пред да ги споделите за помош.

Листа за проверка

• Секој клуч е зачуван како тајна или променлива на околината, не во кодот.
• Ниту една .env датотека или клуч не е закачен во Git.
• Тајните клучеви се користат само во серверскиот код.
• Ниту една тајна променлива нема јавен префикс како VITE_ или NEXT_PUBLIC_.
• Пребарав низ JavaScript-от на живата страница по префиксот на секој клуч и не најдов ништо.
• Клучевите се ограничени со опсег таму каде што провајдерот дозволува.
• Тестовите и живите клучеви се одделни.
• Платените функции бараат најава и имаат лимити по корисник.
• Секој платен провајдер има таван на трошење или известување.
• Знам како да менувам секој клуч, а секој клуч што некогаш бил изложен е сменет.

Чување на клучевите безбедни на Mythex

Mythex ги држи клучевите надвор од вашиот код и чет на два начина:

• Картичка за барање на тајни. Кога агентот ќе му затреба клуч, прикажува картичка во четот каде внесувате вредност во полиња за формулар, а не во полето за порака, и се чува како тајна на проектот. Видете Тајни во чет.
• Project settings → Secrets, или /secrets во чет, за да додавате или менувате клучеви сами. Видете Променливи на околината и тајни.

По менување на тајна за објавена апликација, објавете повторно за живата апликација да ја земе. Извезените проекти ги исклучуваат тајните, па додајте ги повторно каде и да ги извршувате кодот следниот пат. Ако клуч некогаш се појави во чет, сменете го кај провајдерот.

За остатокот од безбедносната проверка пред лансирање, поминете низ листата за проверка на безбедност за апликации изградени со AI. Ако додавате AI функции, како да ги користите LLM API-ја ги опфаќа клучевите и трошоците подлабоко.

Прашања