Is mijn gevibecodede app veilig?

Gevibecodede apps lekken zelden door slimme hackers. Ze lekken door een paar fouten die steeds terugkomen:

• Een geheime sleutel in de front-end. De front-end is alles wat in de browser van je bezoeker draait. Wie op een website rechts klikt en "Inspecteren" kiest, kan die code lezen. Een geheime sleutel die daar staat, is dus openbaar.
• Een database zonder toegangsregels. De app laat elke gebruiker alleen zijn eigen gegevens zien, maar de database zelf geeft alles aan iedereen die het vraagt.
• Controles alleen in de browser. De knop "Verwijderen" is verborgen voor gewone gebruikers, maar de server controleert niet wie het verzoek stuurt.
• Beheerpagina's die open staan. Een pagina als /admin is niet beveiligd, alleen niet gelinkt.

Alle vier zie je niet als je de app gewoon gebruikt. Daarom denkt de maker vaak dat alles goed is.

Een API-sleutel is een code waarmee je app zich meldt bij een andere dienst, zoals een database, een betaaldienst of een AI-model. Er zijn twee soorten:

• Publieke sleutels zijn bedoeld om in de browser te staan. Ze geven alleen toegang tot wat je zelf openzet.
• Geheime sleutels geven veel of volledige toegang. Die horen alleen op een server, nooit in de browser.

Bij Supabase, de database achter veel vibecode-tools, heet de publieke sleutel de publishable key (vroeger de anon key) en de geheime de secret key (vroeger de service role key). De publieke sleutel mag volgens Supabase (opent in een nieuw tabblad)¹ gewoon in je app staan, maar alleen omdat Row Level Security bepaalt wat iemand ermee kan. De geheime sleutel slaat alle regels over. Die mag nooit in de browser, in een app die je verspreidt of in je code op GitHub.

Hetzelfde geldt voor sleutels van bijvoorbeeld OpenAI, Anthropic, Stripe of Mollie. Staat zo'n geheime sleutel in je front-end, dan kan iedereen op jouw kosten AI-opdrachten doen of bij je betaalgegevens.

Waar horen geheime sleutels dan? In een omgevingsvariabele op de server: een instelling die je code kan lezen maar die niet in de code zelf staat. Of er ergens een geheime sleutel in je app staat, zie je niet als je hem gebruikt. Wij zoeken je project erop na en zetten elke geheime sleutel op de plek waar hij hoort.

Row Level Security (RLS) is een functie van de database (opent in een nieuw tabblad)² die per rij bepaalt wie die rij mag lezen of wijzigen. Een rij is één record, bijvoorbeeld één afspraak of één bericht.

Zonder RLS geldt: wie de publieke sleutel heeft, kan alles lezen. En die sleutel staat, zoals we zagen, in je app. Met RLS gelden regels als: "een gebruiker mag alleen afspraken zien waarvan hij de eigenaar is". De database controleert dat bij elk verzoek, ook als iemand je app omzeilt.

Let op twee dingen:

• RLS aanzetten zonder regels sluit alles af. Dan werkt je app niet meer, en de verleiding is groot om een regel te maken die alles toestaat. Dan ben je terug bij af.
• Een regel als "iedereen die is ingelogd mag alles" beschermt alleen tegen bezoekers zonder account. Iedereen kan een account aanmaken.

Of de regels goed staan, zie je niet aan de buitenkant van je app: alles werkt, ook als iedereen bij alles kan. Het nalopen vraagt kennis van de database. Dat doen we voor je: we kijken elke tabel na en zetten de regels zo dat iedereen alleen ziet wat van hem is.

Alles wat in de browser gebeurt, kan een gebruiker aanpassen. Een verborgen knop kun je zichtbaar maken. Een verzoek naar de server kun je met eenvoudige hulpmiddelen namaken met andere gegevens.

Een voorbeeld: in je app kan een gebruiker zijn eigen profiel bewerken. De pagina stuurt "werk profiel 42 bij". Wat gebeurt er als iemand daar 43 van maakt? Als alleen de browser controleert wie je bent, wordt profiel 43 aangepast. Daarom moet de controle op de server (opent in een nieuw tabblad)³ of in de database zitten, via RLS of via code op de back-end.

Vuistregel: alles wat met rechten, geld of gegevens van anderen te maken heeft, moet aan de serverkant gecontroleerd worden. Dat geldt ook voor beheerpagina's: die moeten om een beheerdersrol vragen, ook als iemand het adres direct intypt. Wij lopen na waar je app op de browser vertrouwt en verplaatsen die controles naar de server of de database.

Staat er een geheime sleutel in je front-end of op GitHub, dan is snel handelen nodig:

1. De sleutel moet worden ingetrokken bij de dienst zelf, en vervangen door een nieuwe. Alleen de sleutel uit je code halen is niet genoeg: hij kan al gekopieerd zijn en staat nog in de geschiedenis van je code (opent in een nieuw tabblad)⁴.
2. De nieuwe sleutel hoort op de server, in een omgevingsvariabele.
3. In de logboeken en rekeningen van de dienst is na te gaan of de sleutel misbruikt is.
4. Ging het om persoonsgegevens? Dan kan het een datalek zijn. Een datalek met risico voor mensen moet je volgens de AVG binnen 72 uur melden bij de Autoriteit Persoonsgegevens (opent in een nieuw tabblad)⁵. Lees meer in Privacy en de AVG.

Het vervangen van de sleutel en het nalopen van de logboeken doen wij. De melding doe jij; wij zetten op een rij wat er gebeurd is. Daarna is het verstandig de rest van je app ook na te lopen, want waar één sleutel stond, staan er vaak meer. Ook het inloggen verdient dan een goede test; zie Inloggen en gebruikers en Testen voordat je live gaat.