Cum păstrezi în siguranță cheile API în aplicația ta

Ca să păstrezi în siguranță cheile API, stochează-le ca secrete sau variabile de mediu pe hostingul tău, folosește-le doar în codul de pe server și nu le lipi niciodată în chat, în fișiere de cod, în capturi de ecran sau într-un repository Git. Dă fiecărei chei permisiunea minimă de care are nevoie, setează limite de cheltuieli la furnizor și, dacă o cheie a fost vreodată scursă, rotește-o — creează una nouă și șterge-o pe cea veche — în loc să o ascunzi doar de unde a apărut.

O cheie API este o parolă pentru un serviciu. Cheia ta OpenAI permite cuiva să cheltuiască banii tăi pe AI; cheia secretă Stripe permite cuiva să emită rambursări; cheia furnizorului tău de email permite cuiva să trimită mesaje în numele tău. Constructorii de aplicații cu AI sunt buni la legarea acestor chei, dar nu întotdeauna atenți la locul unde ajung, așa că acest ghid explică cum le păstrezi în siguranță și cum verifici.

Chei publice și chei secrete

Nu orice cheie este secretă. Să știi diferența te oprește să te panichezi pentru cheia greșită și să ignori cheia potrivită.

Dacă nu ești sigur ce fel de cheie este, verifică documentația furnizorului. Când ai dubii, tratează-o ca fiind secretă.

Pasul 1: Stochează cheile ca secrete, nu în cod

Cheile trebuie să stea în variabilele de mediu sau în setările de secrete ale hostingului tău. Codul tău le citește după nume în timpul rulării (de exemplu process.env.OPENAI_API_KEY), deci valoarea nu apare niciodată în fișierele tale. Pentru context, vezi ce sunt variabilele de mediu și secretele.

Mută fiecare cheie API din cod în variabile de mediu. Fă o listă cu fiecare cheie pe care ai găsit-o, în ce fișier era și ce nume de variabilă ai folosit. Nu-mi arăta valorile.

Apoi verifică să nu mai rămână nimic:

Caută în tot proiectul, inclusiv în fișierele de configurare și în orice fișier .env, orice ce pare o cheie API sau o parolă. Raportează fișierul și linia, nu valoarea.

Pasul 2: Folosește cheile secrete doar pe server

Aceasta este regula cea mai importantă. Orice primește browserul, un vizitator poate citi — sursa paginii și fișierele JavaScript sunt vizibile în instrumentele de dezvoltator.

Deci, dacă aplicația trebuie să apeleze OpenAI, browserul ar trebui să apeleze serverul tău, iar serverul apelează OpenAI cu cheia. Cheia nu părăsește niciodată serverul.

Funcția de chat apelează OpenAI direct din browser. Mută apelul într-o rută API de pe server care citește OPENAI_API_KEY din mediu. Browserul ar trebui să apeleze doar ruta noastră. Cere autentificare pentru ruta respectivă.

Fii atent la o capcană frecventă în framework-urile frontend: variabilele cu prefix public — VITE_ în Vite, NEXT_PUBLIC_ în Next.js — sunt incluse în codul din browser în mod intenționat. O cheie secretă cu unul dintre aceste prefixe este expusă, chiar dacă este „într-o variabilă de mediu”.

Pasul 3: Testează că nimic nu se scurge

Nu presupune că a funcționat — verifică site-ul live:

1. Deschide aplicația publicată într-un browser.
2. Deschide instrumentele de dezvoltator, apoi fila Sources sau Network.
3. Caută în toate fișierele primele caractere ale fiecărei chei secrete (de exemplu sk_ sau sk-).
4. Verifică cererile de rețea pe care le face aplicația. O cerere care merge direct din browser către un furnizor AI plătit este un semnal de alarmă.

Dacă găsești o cheie secretă, mut-o pe server (pasul 2) și rotește-o (pasul 6), pentru că era deja publică.

Pasul 4: Restricționează ce poate face fiecare cheie

Mulți furnizori îți permit să limitezi o cheie:

• Chei cu permisiuni limitate care pot face doar ce are nevoie aplicația ta. Stripe, de exemplu, acceptă chei restricționate cu permisiuni specifice.
• Restricții de domeniu sau de IP pentru cheile care trebuie să fie publice, cum sunt cele pentru hărți.
• Chei separate per aplicație și per mediu, ca o singură scurgere să nu expună totul, iar revocarea uneia să nu strice celelalte.
• Chei de test în timpul construirii, iar cheile live doar în aplicația publicată.

Pasul 5: Pune un plafon la daune

Chiar și o cheie bine protejată poate fi folosită abuziv prin propria ta aplicație — de exemplu, cineva care scriptează funcția ta AI de mii de ori.

• Setează limite sau alerte de cheltuieli la fiecare furnizor plătit.
• Cere autentificare pentru orice funcție care costă bani per apel.
• Adaugă o limită de rată per utilizator. Vezi ce este limitarea ratei.

Adaugă o limită de 30 de cereri AI per utilizator pe oră pentru /api/chat. Returnează un mesaj clar când limita este atinsă. Respinge cererile de la utilizatorii care nu sunt autentificați.

Pasul 6: Rotește cheile care au fost scurse

Dacă o cheie secretă apare undeva unde nu ar trebui — un mesaj în chat, un commit, o captură de ecran, un tichet de suport, codul din browser — presupune că a fost compromisă.

1. Creează o cheie nouă la furnizor.
2. Actualizează secretul în setările aplicației tale.
3. Redeployează sau publică din nou, ca aplicația live să folosească cheia nouă.
4. Șterge vechea cheie la furnizor.
5. Verifică jurnalele de utilizare ale furnizorului pentru activitate pe care nu o recunoști.

Ștergerea mesajului din chat sau a commit-ului Git nu este suficientă. Istoricul Git păstrează versiunile vechi, iar tot ce a fost public poate fi deja copiat.

Greșeli frecvente

• Lipirea unei chei în prompt. Acum se află în istoricul chatului. Folosește în schimb un formular de secrete.
• Un prefix public la o variabilă secretă. VITE_OPENAI_API_KEY trimite cheia fiecărui vizitator.
• Trimiterea unui fișier .env în Git. Asigură-te că este în .gitignore înainte de primul push.
• O singură cheie peste tot. Folosește chei separate pentru test și live și pentru fiecare aplicație.
• Lipsa unei limite de cheltuieli. O cheie scursă sau abuzată, fără plafon, poate consuma o factură mare înainte să observi.
• Ascunderea în loc de rotire. Odată ce o cheie a fost expusă, doar una nouă o remediază.
• Chei în capturi de ecran. Decupează sau estompează paginile de setări înainte să le trimiți pentru ajutor.

Listă de verificare

• Fiecare cheie este stocată ca secret sau variabilă de mediu, nu în cod.
• Niciun fișier .env sau nicio cheie nu este trimis în Git.
• Cheile secrete sunt folosite doar în codul de pe server.
• Nicio variabilă secretă nu folosește un prefix public precum VITE_ sau NEXT_PUBLIC_.
• Am căutat în JavaScript-ul site-ului live prefixul fiecărei chei și nu am găsit nimic.
• Cheile sunt limitate sau restricționate acolo unde furnizorul permite.
• Cheile de test și cele live sunt separate.
• Funcțiile plătite cer autentificare și au limite per utilizator.
• Fiecare furnizor plătit are un plafon sau o alertă de cheltuieli.
• Știu cum să rotesc fiecare cheie, iar orice cheie care a fost vreodată expusă a fost rotită.

Păstrarea cheilor în siguranță pe Mythex

Mythex ține cheile departe de cod și de chat în două moduri:

• Cardul de cerere de secrete. Când agentul are nevoie de o cheie, arată un card în chat unde introduci valoarea în câmpuri de formular, nu în caseta de mesaj, iar ea este stocată ca secret al proiectului. Vezi Secretele în chat.
• Project settings → Secrets, sau /secrets în chat, ca să adaugi sau să schimbi chei tu însuți. Vezi Variabilele de mediu și secretele.

După ce schimbi un secret pentru o aplicație publicată, publică din nou, ca aplicația live să-l preia. Proiectele exportate nu includ secretele, deci adaugă-le din nou oriunde rulezi codul data viitoare. Dacă o cheie apare vreodată în chat, rotește-o la furnizor.

Pentru restul verificării de securitate dinaintea lansării, parcurge lista de verificare de securitate pentru aplicațiile construite cu AI. Dacă adaugi funcții AI, cum să folosești API-urile LLM acoperă mai în detaliu cheile și costurile.

Întrebări