Geef ons een willekeurige app die je met Claude, Cursor of Lovable hebt gebouwd, en we breken hem gemiddeld binnen 20 seconden open. Klinkt arrogant? Het is realiteit. En zelfs na 5 correctierondes waarin de AI plechtig verzekert dat alles nu waterdicht is, lukt het ons nog steeds in een minuutje. Het is niet erg dat dit zo is. Erg wordt het pas als jij denkt dat het anders zit.
Moet je dan stoppen met AI-coding tools? Nee. Honderd keer nee. Je moet ze juist gebruiken: ze maken software bouwen sneller en toegankelijker dan ooit. Maar laat de beveiliging niet over aan de AI die de code schreef. Dat moeten wij doen.
20 seconden, gemiddeld
We doen het bijna dagelijks. Iemand stuurt zijn ZIP-bestand op of geeft ons een live URL. Voordat de koffie koud is, hebben we toegang tot de database, kunnen we als admin inloggen, of staan we in een paneel waar we niet hoorden te komen. Niet omdat de AI slechte code maakt. Wel omdat AI-tools defensief denken niet ingebouwd hebben. Ze bouwen wat je vraagt, niet wat een aanvaller probeert.
Waarom AI-tools security niet "snappen"
Een AI-coding tool optimaliseert voor: werkende functies, leesbare code, snel resultaat. Wat hij niet doet: nadenken vanuit een aanvaller. Een aanvaller stuurt geen normale input. Hij stuurt een lege string, een SQL-injectie, een gigantische payload, een verzoek namens een andere gebruiker, of een endpoint dat de developer is vergeten af te schermen.
Vraag een AI om een feature toe te voegen, en hij voegt 'm toe. Vraag of de app veilig is, en hij zegt vol overtuiging "ja". Vraag waar de zwakke plekken zitten, en je krijgt een rijtje met theoretische zorgen, geen concrete bugs. Vertrouw die zelfevaluatie nooit. Het is alsof je een student vraagt zijn eigen tentamen na te kijken.
Veldverhalen: 8 issues die we al hebben opgelost
Een greep uit wat we de afgelopen maanden tegenkwamen, gerangschikt naar hoe vaak we ze tegenkomen. Geen theorie, dit waren echt werkende apps van klanten die ons hun ZIP gaven.
API-key zichtbaar in de browser
Een Lovable-app waarin de Supabase-service-key in de frontend-bundle stond. Met die ene key konden we de hele database lezen, alle gebruikers bekijken en records wissen. Onze fix: backend-laag tussen frontend en database, alleen anonieme keys in de browser, service-keys in versleutelde environment variables.
Admin-routes zonder check
Een Cursor-app met /admin/users die werkte zonder enige authenticatie. Iedereen die het pad kende kon gebruikers aanmaken, verwijderen of als willekeurige gebruiker inloggen. Onze fix: middleware die op elke admin-route de rol verifieert, plus rate limiting op login-pogingen.
Row-level-security die niet werkte
Een v0-app met RLS-policies in de database die op het eerste gezicht klopten. Bij testen bleek dat ze alleen golden voor authenticated requests, niet voor service-rol-requests die de app zelf maakte. Iedere gebruiker zag andermans data. Onze fix: RLS herzien per tabel, expliciete user-context in elke query, en penetratietests met meerdere accounts.
Wachtwoorden in plain text
Een Claude-Code-app waarin wachtwoorden ongehasht in de database werden opgeslagen. Bij een data-lek zou elke gebruiker direct misbruikt kunnen worden, vaak ook bij andere diensten. Onze fix: bcrypt of Argon2 hashing, password reset-flow, advies over MFA en duidelijke breach-procedure.
SQL-injectie via filter-parameter
Een dashboard waar je via de URL een sortering kon kiezen. De parameter werd direct in de SQL-query gestopt. Met één aangepaste URL konden we de hele user-tabel uitlezen, inclusief wachtwoord-hashes en e-mails. Onze fix: alle queries via een ORM met geparametriseerde queries, allow-listing van toegestane sortcolumns, validatie op alle input.
IDOR: data van andere gebruikers via ID's
Een SaaS-app waar /api/orders/123 de order van klant 123 toonde. Verander 123 in 124 en je zag de order van een andere klant. Geen permission-check op object-niveau. Onze fix: elke read-operatie checkt of de huidige gebruiker eigenaar is van het object, plus audit-logs van alle access-patronen.
Geen rate limiting op login
Een AI-gegenereerd inlogscherm zonder enige beperking op aantal pogingen. Met een script konden we 1000 wachtwoorden per minuut proberen. Voor een gebruiker met een zwak wachtwoord is dat binnen seconden over. Onze fix: exponentiele backoff per IP en account, captcha na 3 mislukte pogingen, alerts bij vermoedelijke brute-force.
Onbeperkte file-uploads
Een Claude-app met een upload-formulier dat alle bestandstypen en alle groottes accepteerde. We uploadden een 5GB-bestand, met als resultaat dat de hele app onbruikbaar werd. Een aanvaller kon ook executables plaatsen die later via een andere route uitgevoerd konden worden. Onze fix: maximum bestandsgrootte, allow-list van extensies, virus-scanning, opslag buiten de webroot.
Bijna geen van deze issues is een complexe wiskundige zwakte. Het zijn allemaal patronen die security-experts in hun slaap herkennen, maar die AI-tools structureel missen omdat ze niet vanuit aanvallersperspectief denken.
De gevaarlijkste illusie: "Claude zegt dat het veilig is"
We zien het zo vaak dat we er een naam voor hebben: het "veilig-volgens-de-AI"-effect. Je vraagt je AI of de code veilig is. Hij zegt dat het lijkt te kloppen, noemt een paar best practices die zijn toegepast, en geeft je het gevoel dat het in orde is.
Vervolgens scannen wij dezelfde code en vinden binnen een paar minuten drie ernstige issues. Niet omdat de AI loog, wel omdat hij niet weet wat hij niet weet. Hij ziet de code, niet het gat in de afdekking ervan.
"Ja, dit is veilig"
Geeft een geruststellend antwoord op basis van zichtbare patronen in de code. Mist structureel logische gaten, vergeten endpoints en context-issues.
"Hier zitten 7 problemen"
Specialisten met aanvallersmindset, gestructureerde checklists, automated scanning tools en handmatige tests vinden wat de bouwer zelf niet ziet.
De checklist die je hoort te doorlopen
Onderstaande punten beoordelen we standaard voor elke app die we in onderhoud nemen. Je kan ze ook zelf langslopen, maar realiseer: zelfs als je 'ja' op alles antwoordt, betekent dat niet dat je app veilig is. Het betekent dat de bekende fouten zijn vermeden.
Geen secrets in de frontend-code
Open je gedeployde app in de browser, druk F12, zoek in de bundle naar "key", "secret", "token". Als je iets vindt: dat is openbaar. Veronderstel dat de hele wereld het al heeft.
Authenticatie op elke beschermde route
Klik in je app op alle admin-, beheer- en eigenaar-functies. Open een incognito-venster, plak de URL erin. Krijg je toegang? Dan zit er geen middleware op. Dat moet wel.
Object-level permissions
Maak twee accounts. Bekijk gegevens van account A. Verander de URL naar het ID van account B's gegevens. Zie je ze? Dan ontbreekt object-level autorisatie. Een klassieker.
Rate limiting op gevoelige endpoints
Login, password reset, registratie, OTP-aanvragen. Test of je 100 keer per minuut een poging kan doen. Kan dat? Dan ben je een doelwit voor brute-force.
Input-validatie op alle parameters
Stuur lege strings, gigantische strings, SQL-injectie-pogingen, JavaScript-payloads. Een goed beveiligde app weigert ze of behandelt ze als gewone tekst, geen executie.
HTTPS en goede headers
Geen HTTP. Strict-Transport-Security, Content-Security-Policy, X-Frame-Options en X-Content-Type-Options als minimum. Tools als securityheaders.com geven je in 5 seconden de score.
Dependencies up-to-date
npm audit, pip-audit of een SCA-tool als Snyk laat zien welke van je libraries bekende kwetsbaarheden hebben. Critical en high binnen 7 dagen patchen, geen excuses.
Logging en monitoring
Als er iets mis gaat (en dat gaat het), wil je het binnen minuten weten. Audit-logs op gevoelige acties, alerts bij vreemde patronen, en een dashboard om te zien wat er gebeurt.
"Maar mijn app is niet belangrijk genoeg om gehackt te worden"
Dat is een misverstand dat we elke week horen. Aanvallers richten zich niet op jouw app omdat jij interessant bent. Ze scannen het hele internet op kwetsbaarheden en verwerken massaal wat ze vinden. Wachtwoorden om door te verkopen, e-mailadressen om phishing op te sturen, servers om als botnet in te zetten.
Een nieuwe gedeployde app krijgt binnen 24 uur de eerste scan-bots over zich heen. Niet omdat iemand jouw app kent, maar omdat geautomatiseerde tools het hele IP-bereik aflopen. Klein zijn beschermt je niet, alleen sterke afdekking.
Zelf doen of laten doen?
Eerlijk: een ervaren security-engineer kan dit zelf. Voor één project, als ze de tijd ervoor krijgen, en als ze niet ook nog onder druk staan om de app op te leveren. In de praktijk zien we drie types makers en voor twee daarvan is uitbesteden de juiste keuze.
Werkt voor specialisten
Heb je security-ervaring, tijd, en een testomgeving om aanvallen te simuleren? Doe het zelf. Realiseer wel: het verandert continu.
Beter voor 95% van de cases
Wij doen dit dagelijks, kennen de patronen die AI-tools missen, hebben automated scanners draaien, en houden je app veilig over tijd, niet alleen op dag één.
Conclusie: blijven bouwen, slimmer beveiligen
De boodschap is niet "stop met Claude, Cursor of Lovable gebruiken". Die tools zijn een revolutie in hoe snel je waarde kan leveren. Maar de revolutie heeft een schaduwkant: software-bouwen is toegankelijker dan security-bouwen, en die kloof groeit.
Bouw met je AI-tools. Lever sneller dan ooit. Maar laat de beveiliging niet over aan diezelfde AI. Lever je ZIP bij ons in en wij regelen de hardening, monitoring en doorlopende patches. Jij blijft bouwen, wij houden de aanvallers buiten de deur.