De Snelheidsval van AI-Gestuurde Ontwikkeling

Laten we eerlijk zijn: we hebben het allemaal meegemaakt. Een middagje pielen met Lovable, Bolt of Cursor, en voor het avondeten heb je een live URL. Het voelde als tovenarij. De platformen regelden de hosting, SSL was automatisch geregeld, en je kleine side project was plotseling echt.

Maar hier is de ongemakkelijke waarheid waar ik steeds wieder op stuit: snel uitleveren betekent niet veilig uitleveren. En als iemand die de vibe coding revolutie heeft zien ontvouwen, denk ik dat we moeten praten over wat die pipeline van middag-naar-URL eigenlijk achterlaat.

Een recente diepgaande analyse scande 155 vibe-coded applicaties die developers publiek hadden gelanceerd. Negenennegentig waren nog steeds live en te scannen. De resultaten? Evenzeer bemoedigend als zorgwekkend — en ze zouden moeten veranderen hoe we nadenken over pre-launch checklists.

Het Goede Nieuws: Geheimen Blijven Verborgen

Wat me aangenaam verraste: slechts 1% van de gescande apps lekte daadwerkelijke secret keys naar de browser.

Geen blootgestelde OpenAI API keys die iemands budget verbrandden. Geen AWS credentials die rondzwierven in client-side JavaScript. Geen Stripe live keys die klaar waren om een bankrekening leeg te trekken.

Dit vertelt me iets belangrijks: de moderne AI coding platformen hebben hun standaardinstellingen daadwerkelijk verbeterd. Wanneer je een nieuw project aanmaakt in Bolt of Replit, begeleidt het platform je naar edge functions voor geheimen in plaats van ze in de browser bundle te dumpen. Dat is oprecht goede UX-design voor veiligheid.

Maar één procent is nog steeds één procent te veel. Eén blootgestelde key kan een OpenAI-rekening van €50.000 zijn, een gecompromitteerd AWS-account, of een Stripe-disput die je startup torpedeert voordat hij van de grond komt. Wees niet die ene procent.

Het Supabase-Probleem Waar Niemand Het Over Heeft

Hier wordt het echt lastig.

37% van de live vibe-coded apps bevat een Supabase anonymous key in hun frontend code. En voordat je in paniek raakt — dat is eigenlijk verwacht. Supabase is hiervoor ontworpen. De anon key is bedoeld om publiek te zijn; je data-veiligheid zou moeten komen van Row Level Security (RLS) policies.

Hier is het probleem: RLS is opt-in. Tabellen beginnen volledig open. En wanneer je om 23:00 aan het vibe coden bent, racend naar je lanceringsdeadline, is het opvallend makkelijk om dat checkboxje te missen.

Elke tabel met uitgeschakelde RLS — of erger, een luie using (true) policy — is een deur wijd open voor iedereen met die publieke anon key. Een aanvaller hoeft niets te hacken. Ze kunnen gewoon... je database queryen, omdat je één instelling bent vergeten.

Ik kan dit niet genoeg benadrukken: passieve scanning kan RLS-misconfiguraties niet detecteren. De scanner ziet alleen de frontend. De kwetsbaarheid leeft in je database. Je moet dit handmatig controleren, tabel voor tabel, voordat je live gaat.

Dezelfde advise is van toepassing op Firebase (dat in 4% van de gescande apps voorkwam). Security rules zijn geen optionele extra's. Ze zijn het hele security model.

Security Headers: De Onzichtbare Takenlijst

Als je nooit hebt nagedacht over HTTP security headers, ben je niet de enige. 91% van de gescande apps mist een Content-Security-Policy, en 88% kan worden ingebed in iframes op elke willekeurige website (hallo, clickjacking).

Dit zijn geen exotische kwetsbaarheden. Het zijn standaard hardening stappen die al jaren best practice zijn. De vibe coding pipeline neemt ze alleen... niet standaard mee.

Hier is de uitsplitsing uit de scan:

• 91% mist Content-Security-Policy
• 88% mist X-Frame-Options / frame-ancestors
• 37% mist X-Content-Type-Options
• 38% mist Referrer-Policy
• 8% mist Strict-Transport-Security
• Slechts 5% had alle security headers correct geconfigureerd

Het lichtpuntje? Hosting platformen regelen HSTS automatisch, dus dat is grotendeels gedekt. Maar de CSP-kloof is significant. Wanneer een AI-geschreven component door gebruikers gegenereerde content rendert of third-party scripts integreert, is een CSP je laatste verdedigingslinie. Zonder die headers heeft XSS nergens om zich te verstoppen.

De Launch Polish Kloof

Hier is een bevinding waarvan ik niet verwachtte dat ik om zou geven, maar dat nu wel doe: 30% van de vibe-coded apps lanceert zonder Open Graph tags.

Dat betekent dat wanneer iemand je product deelt op X (Twitter), Discord of LinkedIn, het verschijnt als een kale URL zonder preview image, zonder titel, zonder beschrijving. Gewoon... tekst. In 2024 ziet dat er amateuristisch uit en vermoordt het click-through rates.

Bijkomende lanceringsdag-oversights uit de scan:

• 11% had geen meta description
• 77% had geen sitemap.xml
• Algemene security grades kamen uit op gemiddeld een B-min (84/100), met slechts 13% die een A verdienen

De apps waren geen rampen — ze hadden gewoon polish nodig. Dezelfde snelheid die je naar de lancering brengt, is de snelheid waarmee je vergeet dat <meta property="og:title"> tagetje.

Mijn 5-Minuten Pre-Launch Checklist

Na het doorlezen van dit onderzoek heb ik mijn persoonlijke lanceringschecklist bijgewerkt. Hier is wat er echt toe doet voordat je die Show HN-thread post:

1. Zoek naar secrets in je bundle Doorzoek je gebouwde output naar sk-, sk_live_, service_role, ghp_. Alles wat matcht wordt onmiddellijk geroteerd en verplaatst naar een edge function of environment variable. Eén blootgestelde key is genoeg.

2. Audit elke Supabase of Firebase tabel Open je dashboard. Elke publieke tabel heeft RLS nodig. Elke policy moet specifiek zijn — nooit using (true). Lees-toegang tot één verkeerd geconfigureerde tabel kan je hele gebruikersdatabase blootleggen.

3. Voeg deze security headers toe

Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Start met Content-Security-Policy-Report-Only als je wilt testen zonder enforcement. Maar zorg dat het uitgerold wordt.

4. Schakel productie source maps uit Je *.map bestanden zijn debugging goud voor jou — en voor aanvallers. De meeste platformen hebben hiervoor een toggle. Zet hem uit voor de lancering.

5. Voeg je Open Graph metadata toe Minimaal: og:title, og:description, og:image. Je launch post verdient het er goed uit te zien in een timeline.

6. Genereer een sitemap.xml Je toekomstige SEO-zelf zal je dankbaar zijn. De meeste platformen genereren deze automatisch — check of die van jou dat heeft gedaan.

Het Grotere Plaatje

Hier is mijn kijk: vibe coding is niet het probleem. Het probleem is de kloof tussen "het werkt op mijn machine" en "het is productie-klaar". Traditionele developers leerden deze kloof door jaren van pijnlijke deployments. Vibe coders leren het sneller — en dat is eigenlijk goed.

De platformen verbeteren. De standaardinstellingen worden beter. Maar totdat security hardening zo automatisch is als SSL certificaten, ligt de verantwoordelijkheid bij ons als bouwers om die vijf-minuten checklist toe te voegen vóór de lancering.

De snelheid van vibe coding is een superkracht. Security hoeft niet de prijs te zijn die je ervoor betaalt.

Wat is jouw pre-launch security routine? Laat je checklist-verbeteringen in de reacties achter — ik ben altijd op zoek om de mijne te verbeteren.