Mijn API-sleutels staan in de frontend. Hoe erg is dat?

Iemand kijkt mee in je code, of je leest zelf een keer goed door wat je AI-tool heeft neergezet, en daar staat je sleutel. Gewoon, leesbaar, in een bestand dat naar de browser gaat. De eerste reactie is paniek. Dat is soms terecht en soms niet, en het verschil is precies te bepalen.

Twee soorten sleutels

De ene soort is bedoeld om openbaar te zijn. Je publieke Supabase-sleutel, je publieke Stripe-sleutel, je Google Maps-sleutel: die zitten in elke site die ze gebruikt en dat is geen fout. Ze zeggen alleen wie je bent, niet wat je mag. Wat je mag wordt ergens anders bepaald.

De andere soort mag nooit de browser in. Dat zijn de sleutels die alle regels overslaan: de service-sleutel van je database, je geheime betaalsleutel, je OpenAI- of Anthropic-sleutel, je mailsleutel. Wie die heeft, kan alles wat jij kan.

Zo zie je welke je hebt

• Staat er ergens het woord service, secret, private of admin in de naam of de sleutel zelf? Dan is het de gevaarlijke soort.
• Begint een Stripe-sleutel met sk_, dan is hij geheim. Begint hij met pk_, dan niet.
• In veel frameworks bepaalt het voorvoegsel van de omgevingsvariabele of hij de browser in gaat. Staat er PUBLIC in de naam, dan gaat hij mee, altijd.
• Twijfel je? Open je live site, druk op F12, tabblad Sources, en zoek op de eerste tekens van je sleutel. Vind je hem, dan staat hij openbaar.

De publieke sleutel is niet je beveiliging

Hier gaat het bij AI-gebouwde apps meestal echt mis. De publieke database-sleutel is prima om te delen, maar alleen als de regels op je tabellen kloppen. Doet je app de controle in het scherm, met een verborgen knop of een pagina waar je niet komt zonder inloggen, dan is dat geen slot maar een gordijn. Wie de sleutel heeft, praat rechtstreeks met je database en slaat je hele voorkant over.

Een publieke sleutel is geen lek. Een publieke sleutel op een database zonder regels is dat wel.

Wat je doet als het de verkeerde soort is

Vervang hem, in die volgorde: eerst een nieuwe aanmaken, dan overal invullen waar hij nodig is, dan pas de oude intrekken. Ga er daarna van uit dat de oude sleutel gebruikt is, ook als je niets geks ziet. Kijk in de logs van de dienst wat er de afgelopen weken mee is gedaan.

En haal hem uit je git-geschiedenis, of accepteer dat hij daar staat en trek hem dus echt in. Een sleutel uit een oude commit is net zo bruikbaar als een sleutel uit de huidige.

Hoe je het structureel oplost

Alles wat geheim moet blijven, gaat naar een stukje code dat op de server draait: een route of een edge function. Je browser vraagt daar iets aan, die server praat met de dienst en stuurt alleen het antwoord terug. Dat is een half uur werk per dienst en het is niet ingewikkeld, alleen makkelijk over te slaan als je snel iets werkend wilde hebben.

Weet je niet zeker wat er in jouw project openstaat, dan is dat precies waar de vibecode-scan naar kijkt. Je krijgt terug wat er ligt en wat er als eerste moet gebeuren.