Security-check voor je app

Je app werkt, dus hij is klaar? Nee: AI-bouwers maken apps die werken, niet per se apps die dicht zitten. Doe deze check vóór je echte gebruikers binnenlaat.

Na deze les heb je: je app langs tien checks gehaald, met gratis tools, en je weet wat je doet als er toch iets lekt.

Zo ging het mis bij anderen

Wat	Wanneer	Oorzaak	Gevolg
Lovable (CVE-2025-48757)	gemeld mrt 2025	RLS ontbrak of was fout in gegenereerde apps	170 van 1.645 gescande apps lekten e-mails, betaalgegevens en API-sleutels. Bij één app zetten de onderzoekers zelf de betaalstatus op “paid”.
Moltbook	jan-feb 2026	Supabase-sleutel in de frontend én geen RLS	1,5 miljoen API-tokens en 35.000 e-mailadressen leesbaar en aanpasbaar.
Base44	jul 2025	Registratie-endpoints van het platform zonder controle	Met alleen een publiek zichtbaar app-ID kon je een account maken op “private” apps. Binnen 24 uur gefikst.

Het patroon: niemand brak in, de deur stond open. Twee begrippen die je moet kennen:

• RLS (Row Level Security): regels in je database die bepalen welke rijen iemand mag zien. Uit = iedereen met je project-URL kan alles lezen, wijzigen en verwijderen.
• Publishable vs. secret key: de publishable key (sb_publishable_…, vroeger anon) mag in de browser. De secret key (sb_secret_…, vroeger service_role) omzeilt RLS en hoort alleen op een server.

De tien checks

#	Check	Zo test je het
1	RLS op elke tabel	Supabase → Advisors → Security Advisor: nul errors. Maak dan twee testaccounts en kijk of account B iets van account A ziet of kan wijzigen.
2	Geen geheime sleutels in de frontend	Open je live site → DevTools (F12) → zoek in alle bestanden (Ctrl+Shift+F, Mac: Cmd+Option+F) op sb_secret, service_role, sk- en sk-ant-. Eén treffer = probleem.
3	Login op elke pagina, serverzijdig gecheckt	Log uit en open elke pagina en elke /api/…-URL direct in je browser. Kom je erin, dan controleert alleen de knop, niet de server.
4	Rate limiting	Vraag je AI-bouwer: “Waar zit een limiet op login, aanmelden en elke AI-aanroep?” Zonder limiet betaal jij de AI-rekening van een ander.
5	Invoercontrole	Typ <script>alert(1)</script> en een enorm lange tekst in elk formulier. Popup of crash? Dan wordt invoer niet gecontroleerd. Alleen op je eigen app.
6	Dependency-audit	npm audit --omit=dev in je projectmap, of zet Dependabot alerts aan op GitHub.
7	Security headers	Scan je URL met securityheaders.com of de MDN HTTP Observatory. Streef naar een A.
8	Backups	Kijk in je Supabase-dashboard welke backups je plan heeft, en exporteer zelf maandelijks je data.
9	Logging en alarmen	Weet waar je Supabase-logs staan en zet een budgetalarm bij elke AI-provider.
10	Privacyverklaring en AVG	Privacyverklaring online, verwerkersovereenkomst met elke dienst die persoonsgegevens krijgt, EU-regio gekozen waar het kan.

Gratis tools

Tool	Wat het vindt	Waar
Supabase Security Advisor	Tabellen zonder RLS (lint 0013_rls_disabled_in_public), policies die niet actief zijn	Supabase Studio → Advisors
npm audit	Bekende kwetsbaarheden in je packages	Terminal, in je projectmap
Dependabot + secret scanning	Kwetsbare packages en gelekte sleutels in je repo	GitHub → je repo → Settings → Advanced Security
securityheaders.com / MDN HTTP Observatory	Ontbrekende security headers	In je browser
OWASP ZAP baseline	Passieve scan: kijkt rond, valt niet aan	docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t https://jouw-app.nl

Scan alleen je eigen app. Andermans site scannen zonder toestemming kan strafbaar zijn.

Laat de AI zijn eigen code auditen

Open een nieuwe sessie (of een ander model) en plak:

Je bent een security-reviewer. Verander nog niets.
1. Maak een lijst van elke databasetabel. Per tabel: staat RLS aan, welke policies zijn er voor anon en authenticated, en kan gebruiker A rijen van gebruiker B lezen of wijzigen? Toon de SQL.
2. Zoek in alle frontend-code naar sleutels, tokens en URL's met wachtwoorden. Welke horen op de server? Geef bestand en regel.
3. Maak een tabel van alle routes en API-endpoints: welke vereisen login, en welke controleren of de gebruiker eigenaar is van de data? Markeer elke route zonder eigenaarscheck.
4. Schrijf een test die met twee testaccounts probeert elkaars data te lezen, te wijzigen en te verwijderen. Rapporteer wat lukte.

Dit is geen garantie. Het model dat de fout maakte, ziet hem vaak niet: in een Lovable-app met 18.697 gelekte records (feb 2026) had de AI de inlogcontrole precies omgekeerd geschreven. Vraag daarom om bewijs (een test die faalt of slaagt), niet om een geruststelling.

Test met twee accounts, niet met één

Bijna elk lek is “gebruiker A ziet de data van gebruiker B”. Met één account merk je dat nooit, want je ziet alleen je eigen spullen. Twee accounts, twee browsers (of één incognito), en probeer elkaars pagina’s en ID’s in de URL.

Een nieuwe sleutel maken trekt de oude niet in

Lekte je Supabase-sleutel? Supabase zegt het zelf: nieuwe sleutels aanmaken trekt oude niet in. Verwijder of deactiveer de gelekte sleutel expliciet. En onthoud waarom het zo erg is: “Policies never apply to a secret key”, dus al je RLS is dan lucht.

Datalek? 72 uur

Lekken er persoonsgegevens, dan meld je dat “zonder onredelijke vertraging en, indien mogelijk, uiterlijk 72 uur” na ontdekking bij de Autoriteit Persoonsgegevens (art. 33 AVG). Alleen als het lek waarschijnlijk geen risico oplevert, hoeft dat niet. Bij een hoog risico (ID-foto’s, wachtwoorden) informeer je ook je gebruikers (art. 34). Elk lek leg je intern vast, ook als je niet meldt.

Security

Als het toch misgaat, doe je in de eerste 15 minuten dit:

• Deur dicht: zet RLS aan op de lekkende tabel, of haal de app offline.
• Sleutels omdraaien: deactiveer elke sleutel die in de frontend of in de gelekte data stond (Supabase, OpenAI, Anthropic, Stripe) en zet uitgavenlimieten.
• Noteer wat, wanneer en hoeveel mensen. De 72-uursklok loopt vanaf het moment dat je het weet.
• Check ook de rest van je AI-gebruik met de security-scan.

Checklist

0/10

• RLS aan op elke tabel, getest met twee accounts
• Geen secret key, service_role of sk-sleutel te vinden in de frontend
• Elke pagina en API-route geweigerd als ik uitgelogd ben
• Rate limiting op login, aanmelden en AI-aanroepen
• Formulieren getest met een script-tag en lange tekst
• npm audit of Dependabot zonder kritieke meldingen
• Security headers gescand (doel: A)
• Backups gecheckt en één eigen export gemaakt
• Weet waar mijn logs staan, budgetalarm aan
• Privacyverklaring en verwerkersovereenkomsten geregeld

Je voortgang wordt alleen in deze browser bewaard.

Test jezelf

1. 1Welke Supabase-sleutel mag in je frontend staan?

   De secret key (sb_secret_ / service_role)De publishable key (sb_publishable_ / anon)Allebei, als RLS aan staat

2. 2Waarom test je RLS met twee accounts?

   Omdat Supabase dat vereistOmdat je met één account niet ziet of je bij de data van een ander kuntOm de rate limiting te testen

3. 3Je ontdekt op maandag 9:00 dat er e-mailadressen lekten. Wanneer meld je uiterlijk bij de AP?

   Binnen een maandIndien mogelijk uiterlijk donderdag 9:00Alleen als een gebruiker klaagt

Klaar met het leerpad Security-basis? Doe de security-scan nog eens en kijk hoeveel er nu op groen staat.