Cursor & v0 Security Fouten 2026: De 5 Grootste Risico's

-- ❌ Hoe AI vaak een tabel aanmaakt (Public by default)
CREATE TABLE users ( id serial primary key, email text );
-- Ontbrekend: ALTER TABLE users ENABLE ROW LEVEL SECURITY;

De Fix:

Hanteer altijd deny-by-default policies. Zet RLS direct aan bij het aanmaken van een tabel en schrijf expliciete policies voor SELECT, INSERT, UPDATE en DELETE.

2. API Keys in Client-Side Code (Het NEXT_PUBLIC_ lek)

Als je aan Cursor vraagt: "Maak een chat-interface met OpenAI", is de kans groot dat de AI de API-aanroep direct in je frontend component zet om het snel werkend te krijgen.

Het Gevaar:

Om CORS-errors of build-fouten te voorkomen, stelt de AI vaak voor om je secret in een variabele zoals NEXT_PUBLIC_OPENAI_API_KEY te zetten. Deze sleutel wordt hierdoor direct mee-gebundeld in je frontend code. Iedereen die de browser source code bekijkt, kan jouw OpenAI (of Stripe!) key stelen.

Hoe dat eruitziet:

// ❌ Direct lek in je React/Next.js component:
const response = await fetch('https://api.openai.com/v1/chat', {
  headers: { 'Authorization': `Bearer ${process.env.NEXT_PUBLIC_OPENAI_API_KEY}` }
});

De Fix:

Verplaats externe API-calls die secrets nodig hebben altijd naar een server-side endpoint (zoals Next.js Route Handlers of Server Actions). Gebruik pure server-only secrets.

3. Ontbrekende security headers (CSP / HSTS)

AI-outputs van tools zoals v0 focussen zich op UI en UX (prachtige Tailwind componenten), niet op server hardening.

Het Gevaar:

Zonder een goede Content Security Policy (CSP) en HTTP Strict Transport Security (HSTS) vergroot je je attack surface enorm. Je app is hierdoor veel kwetsbaarder voor Cross-Site Scripting (XSS) aanvallen of clickjacking, simpelweg omdat de browser niet weet welke scripts hij wel of niet mag vertrouwen.

De Fix:

Start met een duidelijke header baseline. In frameworks zoals Next.js kun je dit eenvoudig instellen in je next.config.js.

4. Onveilige direct database queries (Ontbrekende server boundaries)

Snelle implementaties slaan vaak de veilige server boundaries over. AI genereert soms code waarbij de client direct bepaalt wélke data er wordt opgevraagd, zonder dat de server dit valideert.

Het Gevaar:

Als je frontend direct een query bouwt (zoals supabase.from('invoices').select('*').eq('user_id', userId)), en je RLS staat niet 100% strak, kan een slimme gebruiker die API-call aanpassen om facturen van andere gebruikers op te halen.

De Fix:

Dwing server-side data access af waar mogelijk. Valideer alle inkomende data (bijvoorbeeld met Zod schema's) en minimaliseer query privileges. Vertrouw nooit op data die direct van de client komt.

5. Over-permissive CORS configuraties

Je bent aan het bouwen, je test je nieuwe AI-gecodeerde endpoint, en de browser gooit een dikke rode CORS-error (Cross-Origin Resource Sharing). Wat is de fix van de AI?

Het Gevaar:

De AI stelt vaak de "makkelijke" route voor: "Even tijdelijk" Access-Control-Allow-Origin: * toevoegen. Hiermee mag plotseling elke website op het internet data van jouw API opvragen. Die "tijdelijke" fix blijft vervolgens veel te vaak in productie staan.

De Fix:

Whitelist expliciete origins per environment (bijv. alleen jouw vercel.app domein voor staging, en je hoofddomein voor productie).

Jouw AI-Release Checklist

Voorkom dat je snelheid betaalt met security. Loop deze checklist na bij je volgende release:

Veelgestelde Vragen over AI-Code Security (FAQ)