Hoe je API-sleutels veilig houdt in je app

Om API-sleutels veilig te houden, bewaar je ze als geheimen of omgevingsvariabelen bij je host, gebruik je ze alleen in serversidecode, en plak je ze nooit in de chat, codebestanden, screenshots of een Git-repository. Geef elke sleutel de minst mogelijke rechten die hij nodig heeft, stel uitgavenlimieten in bij de provider, en als een sleutel ooit lekt, vervang hem dan — maak een nieuwe aan en verwijder de oude — in plaats van alleen te verbergen waar hij verscheen.

Een API-sleutel is een wachtwoord voor een dienst. Je OpenAI-sleutel laat iemand met jouw geld AI gebruiken; je Stripe-geheime sleutel laat iemand terugbetalingen doen; je sleutel van de e-mailprovider laat iemand als jou mail versturen. AI-appbouwers zijn goed in het koppelen van deze sleutels, maar ze letten niet altijd op waar ze terechtkomen. Deze gids laat zien hoe je ze veilig houdt en hoe je dat controleert.

Publieke sleutels en geheime sleutels

Niet elke sleutel is geheim. Als je het verschil kent, raak je niet in paniek over de verkeerde en negeer je de juiste niet.

Weet je niet welk type een sleutel is, kijk dan in de documentatie van de provider. Behandel hem bij twijfel als geheim.

Stap 1: Bewaar sleutels als geheimen, niet in de code

Sleutels horen in de omgevingsvariabelen of geheimen-instellingen van je host. Je code leest ze tijdens het draaien bij naam (bijvoorbeeld process.env.OPENAI_API_KEY), zodat de waarde nooit in je bestanden verschijnt. Voor de achtergrond, zie wat omgevingsvariabelen en geheimen zijn.

Verplaats elke API-sleutel uit de code naar omgevingsvariabelen. Maak een lijst van elke sleutel die je hebt gevonden, in welk bestand hij stond, en welke variabelenaam je hebt gebruikt. Laat de waarden niet zien.

Controleer daarna of er niets is achtergebleven:

Doorzoek het hele project, inclusief configuratiebestanden en eventuele .env-bestanden, op alles wat op een API-sleutel of wachtwoord lijkt. Meld het bestand en de regel, niet de waarde.

Stap 2: Gebruik geheime sleutels alleen op de server

Dit is de regel die het meest telt. Alles wat de browser ontvangt, kan een bezoeker lezen — de paginabron en JavaScript-bestanden zijn allemaal zichtbaar in de ontwikkelaarstools.

Dus als de app OpenAI moet aanroepen, roept de browser jouw server aan, en je server roept OpenAI aan met de sleutel. De sleutel verlaat de server nooit.

De chatfunctie roept OpenAI rechtstreeks vanuit de browser aan. Verplaats die aanroep naar een serverroute die OPENAI_API_KEY uit de omgeving leest. De browser mag alleen onze route aanroepen. Vereis inloggen voor de route.

Let op een veelvoorkomende valkuil in frontend-frameworks: variabelen met een publiek voorvoegsel — VITE_ in Vite, NEXT_PUBLIC_ in Next.js — worden bewust in de browsercode gebouwd. Een geheime sleutel met zo'n voorvoegsel wordt blootgesteld, ook al staat hij "in een omgevingsvariabele".

Stap 3: Test dat er niets lekt

Vertrouw er niet op dat het gelukt is — controleer de live site:

1. Open de gepubliceerde app in een browser.
2. Open de ontwikkelaarstools en ga naar het tabblad Sources of Network.
3. Zoek in alle bestanden naar de eerste tekens van elke geheime sleutel (bijvoorbeeld sk_ of sk-).
4. Controleer de netwerkverzoeken die de app doet. Een verzoek dat rechtstreeks van de browser naar een betaalde AI-provider gaat, is een rode vlag.

Vind je een geheime sleutel, verplaats hem dan naar de server (stap 2) en vervang hem (stap 6), want hij was al openbaar.

Stap 4: Beperk wat elke sleutel kan doen

Veel providers laten je een sleutel beperken:

• Beperkte of scoped sleutels die alleen kunnen doen wat je app nodig heeft. Stripe ondersteunt bijvoorbeeld beperkte sleutels met specifieke rechten.
• Domein- of IP-beperkingen voor sleutels die openbaar moeten zijn, zoals kaartsleutels.
• Aparte sleutels per app en per omgeving, zodat één lek niet alles blootlegt en het intrekken van één sleutel de andere niet breekt.
• Testsleutels tijdens het bouwen, en live-sleutels alleen in de gepubliceerde app.

Stap 5: Begrens de schade

Zelfs een goed beschermde sleutel kan verkeerd worden gebruikt via je eigen app — iemand die je AI-functie duizenden keren per script aanroept, bijvoorbeeld.

• Stel uitgavenlimieten of waarschuwingen in bij elke betaalde provider.
• Vereis inloggen voor elke functie die per aanroep geld kost.
• Voeg een limiet per gebruiker toe. Zie wat rate limiting is.

Voeg een limiet toe van 30 AI-verzoeken per gebruiker per uur op /api/chat. Toon een duidelijk bericht wanneer de limiet is bereikt. Wijs verzoeken af van gebruikers die niet zijn ingelogd.

Stap 6: Vervang sleutels die lekken

Als een geheime sleutel ergens verschijnt waar hij niet hoort — een chatbericht, een commit, een screenshot, een supportticket, browsercode — ga er dan van uit dat hij is gecompromitteerd.

1. Maak een nieuwe sleutel aan bij de provider.
2. Werk het geheim bij in de instellingen van je app.
3. Deploy of publiceer opnieuw zodat de live app de nieuwe sleutel gebruikt.
4. Verwijder de oude sleutel bij de provider.
5. Controleer de gebruikslogboeken van de provider op activiteit die je niet herkent.

Het chatbericht of de Git-commit verwijderen is niet genoeg. De Git-geschiedenis bewaart oude versies, en alles wat openbaar was, is mogelijk al gekopieerd.

Veelgemaakte fouten

• Een sleutel in de prompt plakken. Hij staat nu in de chatgeschiedenis. Gebruik in plaats daarvan een geheimenformulier.
• Een publiek voorvoegsel op een geheime variabele. VITE_OPENAI_API_KEY levert de sleutel aan elke bezoeker.
• Een .env-bestand committen. Zorg dat het in .gitignore staat vóór de eerste push.
• Overal dezelfde sleutel. Gebruik aparte sleutels voor test en live, en voor elke app.
• Geen uitgavenlimiet. Een gelekte of misbruikte sleutel zonder limiet kan een grote rekening opleveren voordat je het merkt.
• Verbergen in plaats van vervangen. Zodra een sleutel is blootgesteld, lost alleen een nieuwe sleutel het op.
• Sleutels in screenshots. Knip instellingenpagina's bij of vervaag ze voordat je ze deelt voor hulp.

Checklist

• Elke sleutel is opgeslagen als geheim of omgevingsvariabele, niet in de code.
• Geen .env-bestand of sleutel is in Git gecommit.
• Geheime sleutels worden alleen in serversidecode gebruikt.
• Geen geheime variabele heeft een publiek voorvoegsel zoals VITE_ of NEXT_PUBLIC_.
• Ik heb de JavaScript van de live site doorzocht op het voorvoegsel van elke sleutel en niets gevonden.
• Sleutels zijn beperkt of gescoped waar de provider dat toestaat.
• Test- en live-sleutels zijn gescheiden.
• Betaalde functies vereisen inloggen en hebben limieten per gebruiker.
• Elke betaalde provider heeft een uitgavenlimiet of waarschuwing.
• Ik weet hoe ik elke sleutel vervang, en elke sleutel die ooit is blootgesteld, is vervangen.

Sleutels veilig houden op Mythex

Mythex houdt sleutels op twee manieren uit je code en chat:

• Kaart voor sleutelverzoeken. Wanneer de agent een sleutel nodig heeft, toont hij een kaart in de chat waarop je de waarde invult in formuliervelden, niet in het berichtvak, en hij wordt opgeslagen als projectgeheim. Zie Geheimen in de chat.
• Projectinstellingen → Geheimen, of /secrets in de chat, om zelf sleutels toe te voegen of te wijzigen. Zie Omgevingsvariabelen en geheimen.

Na het wijzigen van een geheim voor een gepubliceerde app, publiceer je opnieuw zodat de live app het oppikt. Geëxporteerde projecten laten geheimen weg, dus voeg ze opnieuw toe waar je de code daarna draait. Als een sleutel ooit in de chat verschijnt, vervang hem dan bij de provider.

Voor de rest van de beveiligingscontrole vóór de lancering, werk je de beveiligingschecklist voor met AI gebouwde apps door. Voeg je AI-functies toe, dan behandelt hoe je LLM-API's gebruikt sleutels en kosten dieper.

Veelgestelde vragen