API-sleutels en omgevingsvariabelen in een browser-IDE

De eerste regel is ongemakkelijk maar simpel: een statische webapp kan geen geheim bewaren. De browser downloadt HTML, CSS en JavaScript en voert die uit op de machine van de gebruiker. Iedereen kan DevTools openen, het netwerkpaneel lezen, de bundel doorzoeken of een breakpoint zetten en een variabele inspecteren. Minificeren, opsplitsen in chunks of een waarde in een configuratiebestand verstoppen verandert de inspanning, niet de uitkomst. Een browser-IDE voegt een sandbox toe voor het uitvoeren van projectcode, maar de interface van de IDE draait nog steeds op dezelfde origin en moet lezen wat hij nodig heeft. De sandbox is geen kluis voor waarden die de interface zelf gebruikt. De bruikbare test is eenvoudig: als een waarde beschikbaar moet zijn voor code in de tab, ga er dan van uit dat de gebruiker hem kan lezen, en dat elk script op dezelfde origin hem ook kan lezen. Dat maakt browserontwikkeling niet onveilig. Het definieert de grens. Publieke identificatoren kunnen erin; serverreferenties niet.

Op een Node.js-server wordt een omgevingsvariabele tijdens runtime uit het proces gelezen. In een build met Vite, Create React App, Next.js of Astro werken publieke omgevingsvariabelen anders: de bundler vervangt verwijzingen tijdens de build door letterlijke strings. Vite stelt variabelen met het voorvoegsel VITE_ beschikbaar via import.meta.env; Create React App gebruikt REACT_APP_; Next.js gebruikt NEXT_PUBLIC_; Astro gebruikt PUBLIC_. Het voorvoegsel is een naamgevingsconventie, geen beveiligingsmaatregel. Zodra een waarde is ingevoegd, maakt hij deel uit van de JavaScript die elke bezoeker downloadt. Een variabele zonder publiek voorvoegsel is normaal gesproken niet beschikbaar voor clientcode; daarom moeten waarden die alleen voor de server bedoeld zijn, door een server of serverless functie worden gelezen, niet door een statische pagina. Een .env-bestand is invoer voor ontwikkeling en build, geen runtime-geheimenopslag. Het is handig voor lokale configuratie en om waarden buiten versiebeheer te houden, maar het maakt een waarde na de build niet privé.

# Safe to expose: a public endpoint
VITE_API_URL=https://api.example.com

# Never expose: keep this on a server
STRIPE_SECRET_KEY=REPLACE_WITH_SERVER_SECRET

Sommige sleutels zijn ontworpen om openbaar te zijn. Een publiceerbare Stripe-sleutel identificeert een account en maakt betaaltokens; de geheime sleutel verplaatst daadwerkelijk geld en moet op een server blijven. Een Supabase anon-sleutel is alleen veilig als de row-level security policies kloppen. Een Firebase-webconfiguratie identificeert een project, maar geeft geen beheertoegang. Sleutels voor kaarten en gebruiksmeting zijn vaak beperkt per domein of API. Deze waarden mogen naar de browser, maar verdienen nog steeds grenzen: toegestane origins, API-beperkingen, rollen met minimale rechten, quota en waarschuwingen. De tegenovergestelde categorie is makkelijker te benoemen. Service-role-sleutels, databasewachtwoorden, SMTP-referenties, ondertekeningsgeheimen en privésleutels van AI-providers horen nooit in een statische bundel. Een providersleutel die bij de applicatie hoort, is extra gevaarlijk: iedereen die hem vindt, kan het geld van de applicatie uitgeven. Een sleutel die bij de gebruiker hoort, is een ander geval. Het blijft een bearer-referentie, maar het is de zijne, en het doel is hem in de browser van de gebruiker te houden in plaats van in het project of de repository.

Het AI-paneel van GB Coder werkt volgens bring-your-own-key. De sleutelbeheerder houdt providersleutels standaard in het geheugen. Hij schrijft ze niet naar localStorage. De gebruiker kan expliciet kiezen voor opslag in sessionStorage; daarmee is de waarde beperkt tot het huidige tabblad en wordt hij normaal gewist wanneer het tabblad sluit. De sleutel wordt uit het geheugen en de sessieopslag verwijderd wanneer de gebruiker hem wist. De beheerder koppelt elke sleutel ook aan een toegestane endpoint-origin, en een uitgaande poort controleert dat een referentie niet naar een bestemming wordt gestuurd waarvoor hij niet is goedgekeurd. Fouten van providers gaan door een redactielaag die sleutelpatronen en actieve sleutels verwijdert voordat het bericht de interface of een log bereikt. Metadata van aangepaste providers wordt in localStorage opgeslagen, maar headers die als geheim zijn gemarkeerd, worden vóór opslag gewist en moeten opnieuw worden ingevoerd. Verzoeken gaan rechtstreeks van de browser naar het endpoint van de provider; GB Coder stuurt de sleutel niet via een LadeStack-server. Deze maatregelen beperken onbedoelde opslag en lekken tussen origins. Ze veranderen de basisregel niet: elk script dat op dezelfde origin kan draaien, kan lezen wat de pagina kan lezen. Gebruik een schoon profiel voor gevoelig werk en installeer geen extensies die je niet vertrouwt.

Houd geheimen buiten de projectmap. Zet .env en de lokale varianten in .gitignore en commit een .env.example met placeholders. Als een project Vite gebruikt, onthoud dan dat elke VITE_-variabele in de productiebundel wordt ingevoegd. Een waarde die tijdens lokale ontwikkeling handig was, wordt openbaar zodra hij in een productiebuild wordt gebruikt. Inspecteer vóór de deployment de gegenereerde assets op sleutelpatronen en behandel een treffer als een incident, niet als een waarschuwing. GitHub secret scanning en push protection kunnen sommige bekende tokenformaten vinden, maar het is een vangnet, geen vervanging voor het buiten de repository houden van waarden. De ZIP-export van een browser-IDE bevat projectbestanden. Als er een .env-bestand in het project staat, reist het mee met de back-up. Een back-up is geen versleutelde kluis. Bewaar exports op een privéplek en verwijder oude kopieën wanneer je ze niet meer nodig hebt. Hetzelfde geldt voor screenshots, issue-rapporten en chatberichten: een sleutel die in een daarvan is geplakt, heeft de browser al verlaten.

# .gitignore
.env
.env.local
.env.*.local

GitHub personal access tokens en deploymenttokens zijn krachtiger dan ze lijken. Een klassiek token met repository- en workflowrechten kan privécode lezen, bestanden wijzigen en releases starten. Geef de voorkeur aan fine-grained tokens met één repository, een expliciete rechtenlijst en een vervaldatum. Geef een token alleen de rechten die de taak nodig heeft: contents lezen en schrijven voor een sync, niet administration of billing. Maak aparte tokens voor aparte apparaten of doelen en trek ze in wanneer het werk klaar is. Deploymenttokens voor Vercel of Netlify kunnen projecten publiceren, vervangen of verwijderen. Als de provider scoping per project of team ondersteunt, gebruik die; als hij vervaldatums ondersteunt, stel er een in. Plak het token alleen in het deploymentpaneel wanneer dat nodig is en sla het niet op in een projectbestand. Gebruik in CI repository- of organisatiegeheimen in plaats van een gecommitte .env, en onthoud dat pull requests van forks normaal gesproken geen geheimen ontvangen. Een token dat is gefotografeerd, in een chat is gedeeld of in een openbare repository is gecommit, moet als gecompromitteerd worden beschouwd, ook als het een seconde later is verwijderd.

Een AI-providersleutel is een bearer-referentie met een rekening eraan vast. Iedereen die hem heeft, kan verzoeken sturen, quota verbruiken en kosten maken. Gebruik een sleutel die aan een project is gekoppeld, stel een uitgavelimiet in als de provider dat biedt, en gebruik een aparte sleutel voor experimenten in plaats van de hoofdsleutel van de organisatie. Controleer het gebruik regelmatig, zeker na het delen van een apparaat of het installeren van een nieuwe extensie. Lokale providers zoals Ollama, LM Studio en vLLM hebben geen cloudsleutel nodig, maar hun endpoints zijn nog steeds diensten op de machine. Stel een lokaal endpoint niet bloot aan het openbare internet alleen om een demo te laten werken. Als een aangepaste provider naar een proxy wijst, kan de proxy de sleutel zien; gebruik alleen een proxy die je beheert en begrijpt. Prompt-injectie is een verwant risico: een bestand, een webpagina of een geplakt foutbericht kan instructies bevatten die op de assistent zijn gericht. Houd geheimen buiten prompts en buiten bestanden die de assistent mag lezen. Als een sleutel in een gesprek verschijnt, roteer hem dan.

Een gedeelde computer of labcomputer vraagt om een andere routine. Gebruik een privé-browserprofiel, kies niet voor sessiepersistentie en sluit het tabblad als je klaar bent. Als de browser aanbiedt de sleutel op te slaan, weiger dat. Wis de opslag van de site als je vermoedt dat die bewaard is gebleven. Browserextensies zijn een ander deel van de grens: een extensie met brede hostrechten kan vaak paginacontent of opslag lezen, en een kwaadaardige update kan binnenkomen nadat je hem hebt geïnstalleerd. Gebruik een minimaal profiel voor werk met referenties. Cross-site scripting is in deze context het klassieke webrisico. Als een aanvaller een script op de origin van de IDE kan uitvoeren, kan dat script localStorage en sessionStorage lezen en verzoeken doen zolang de pagina open is. Houd dependencies actueel, vermijd niet-vertrouwde scripts van derden en overweeg een content security policy op de gedeployde site. Klembordbeheerders en schermdeeltools zien ook wat je kopieert en toont. Wis het klembord nadat je een sleutel hebt verplaatst en pauzeer het delen voordat je een providerinstellingenpaneel opent.

Rotatie is de enige betrouwbare reactie op een uitgelekte sleutel. Eerst intrekken is belangrijk: als de oude sleutel geldig blijft terwijl een vervanger wordt voorbereid, gaat de blootstelling door. Maak de nieuwe sleutel met de smalst mogelijke scope, werk de applicatie of browserinstellingen bij, deploy opnieuw als de waarde deel uitmaakte van een build, en controleer dat de oude sleutel wordt geweigerd. Bekijk daarna het gebruik en de auditlogs van de provider op activiteit die je niet verwachtte. Als de sleutel in Git is gecommit, is het bestand verwijderen niet genoeg; de waarde blijft in de geschiedenis staan. Roteer eerst en herschrijf daarna de geschiedenis met een tool zoals git filter-repo of BFG, force-push in overleg met het team en vraag medewerkers opnieuw te clonen. Hostingplatforms kunnen oude builds cachen, dus zorg dat de oude waarde niet uit een verouderde bundel kan worden geserveerd. Als de sleutel in een AI-chat, een supportticket of een screenshot is geplakt, ga er dan van uit dat hij is bewaard en roteer hem. Leg ten slotte vast wat er is gebeurd, voeg een controle toe die het had kunnen vangen en verkort de levensduur van de volgende sleutel.

Gebruik deze volgorde voordat een project de browser verlaat. Ten eerste, classificeer elke waarde: publieke identificator, gebruikersreferentie of servergeheim. Ten tweede, houd servergeheimen buiten de statische bundel en zet ze achter een serverless functie of API. Ten derde, stel alleen waarden bloot die het publieke voorvoegsel nodig hebben, en inspecteer de gebouwde assets vóór de deployment. Ten vierde, houd .env-bestanden buiten Git, commit een .env.example en schakel secret scanning in. Ten vijfde, maak tokens met scope en vervaldatum voor GitHub en hosting, één per doel. Ten zesde, laat sleutels in GB Coder in het geheugen tenzij je op een vertrouwd apparaat zit, en kies alleen voor sessiepersistentie als je de afweging begrijpt. Ten zevende, plak een sleutel nooit in een prompt, een issue, een screenshot of een projectbestand. Ten achtste, roteer bij twijfel en trek in voordat je vervangt. Ten negende, gebruik een schoon browserprofiel op gedeelde machines. Ten tiende, schrijf het plan voor een lek op voordat je het nodig hebt. Een browser-IDE kan verantwoord met referenties omgaan als hij de browser als een publieke client behandelt en niet als een privékluis.