Fällan med AI-driven utveckling: När hastighet blir säkerhetsrisk

Vi har alla varit där. En eftermiddag med Lovable, Bolt eller Cursor, och till middagen har vi en live-URL. Det känns magiskt. Hosting? Fixat. SSL? Automatiskt. Lilla sido projektet är plötsligt verkligt.

Men här är obehagligheten jag inte kan slippa: att bygga snabbt betyder inte att man bygger säkert. Och efter att ha sett "vibe coding"-revolutionen utvecklas, tror jag vi behöver prata om vad den där eftermiddag-till-URL-pipelinen egentligen lämnar efter sig.

En färsk undersökning scannade 155 vibe-codade applikationer som deras skapare lanserat offentligt. Nittiotal av dem var fortfarande live och scannbara. Resultatet? Lika uppmuntrande som oroande—och det borde förändra hur vi tänker kring våra checklistor innan lansering.

Den goda nyheten: Hemligheter förblir hemliga

Här är vad trevligt överraskade mig: bara en procent av de scannade apparna läckte faktiska nycklar till webbläsaren.

Inga exponerade OpenAI-nycklar som förbränner någon annans budget. Inga AWS-uppgifter som flyter omkring i klient-side JavaScript. Inga Stripe-livenycklar redo att tömma ett bankkonto.

Det här säger mig något viktigt: moderna AI-kodningsplattformar har verkligen förbättrat sina standardvärden. När du skapar ett nytt projekt i Bolt eller Replit guidas du mot edge functions för hemligheter istället för att dumpa dem i webbläsarpaketet. Det är genuint bra UX-design för säkerhet.

Men en procent är fortfarande en procent för mycket. En exponerd nyckel kan bli en OpenAI-räkning på 50 000 kronor, ett komprometterat AWS-konto, eller en Stripe-disput som sänker ditt startup innan det kommit igång. Var inte den procenten.

Supabase-problemet ingen pratar om

Här blir det lite knepigt.

37% av live vibe-codade appar inkluderar en Supabase anonymous key i sin frontend-kod. Och innan du får panik—det är faktiskt förväntat. Supabase är designat så. Anon-nyckeln är avsedd att vara publik; din datasäkerhet ska komma från Row Level Security (RLS) policies.

Här är problemet: RLS är opt-in. Tabeller börjar helt öppna. Och när du vibe-codar klockan 23 och kör för att nå lanseringsdeadlinen, är det förvånansvärt lätt att missa den där checkboxen.

Varje tabell med RLS avaktiverad—eller värre, en lat using (true) policy—är en dörr vidöppen för vem som helst med den publika anon-nyckeln. En angripare behöver inte hacka något. De frågar bara din databas, för att du glömt en enda inställning.

Jag kan inte nog betona detta: passiv scanning kan inte upptäcka RLS-misstconfigurer. Scannern ser bara frontenden. Sårbarheten finns i din databas. Du måste kontrollera detta manuellt, tabell för tabell, innan du kör live.

Samma råd gäller Firebase (som dök upp i 4% av scannade appar). Säkerhetsregler är inga valfria tillägg. De är hela säkerhetsmodellen.

Säkerhetsheaders: Den osynliga att-göra-listan

Om du aldrig tänkt på HTTP-säkerhetsheaders är du inte ensam. 91% av scannade appar saknar en Content-Security-Policy, och 88% kan bäddas in i iframes på vilken webbplats som helst (hej, clickjacking).

Dessa är inga exotiska sårbarheter. De är standard-hårdning som varit bästa praxis i år. Vibe coding-pipelinen inkluderar dem bara... inte som standard.

Här är uppdelningen från scannningen:

• 91% saknar Content-Security-Policy
• 88% saknar X-Frame-Options / frame-ancestors
• 37% saknar X-Content-Type-Options
• 38% saknar Referrer-Policy
• 8% saknar Strict-Transport-Security
• Bara 5% hade alla säkerhetsheaders konfigurerade

Den ljusa fläcken? Hostingplattformar hanterar HSTS automatiskt, så den är mestadels täckt. Men CSP-gapet är signifikant. När en AI-skriven komponent rendrerar användarskapat innehåll eller integrerar tredjepartsscripts, är en CSP din sista försvarslinje. Utan en finns det ingenstans för XSS-attacker att gömma sig.

Poleringen som saknas vid lansering

Här är ett resultat jag inte förväntade mig bry mig om, men verkligen gör: 30% av vibe-codade appar lanseras utan Open Graph-taggar.

Det betyder att när någon delar din produkt på X (Twitter), Discord eller LinkedIn, visas den som en bare URL utan förhandsvisningsbild, utan titel, utan beskrivning. Bara... text. År 2024 ser det amatörmässigt ut och dödar click-through-raten.

Ytterligare lanseringsmissar från scannningen:

• 11% hade ingen meta description
• 77% hade ingen sitemap.xml
• Genomsnittligt säkerhets betyg: B-minus (84/100), med bara 13% som fick ett A

Apparna var inga katastrofer—de behövde bara lite polering. Samma hastighet som tar dig till lansering är samma hastighet som får dig att glömma <meta property="og:title">.

Min 5-minuters checklista före lansering

Efter att ha läst igenom den här forskningen har jag uppdaterat min personliga lanseringschecklista. Här är vad som faktiskt spelar roll innan du postar den där Show HN-tråden:

1. Leta efter hemligheter i ditt bundle Sök i ditt byggda output efter sk-, sk_live_, service_role, ghp_. Allt som matchar roteras omedelbart och flyttas till en edge function eller miljövariabel. En exponerd nyckel är allt som behövs.

2. Granska varje Supabase- eller Firebase-tabell Öppna din dashboard. Varje publik tabell behöver RLS aktiverat. Varje policy behöver vara specifik—aldrig using (true). Läsåtkomst till en felkonfigurerad tabell kan exponera hela din användardatabas.

3. Lägg till dessa säkerhetsheaders

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

Börja med Content-Security-Policy-Report-Only om du vill testa utan enforcement. Men få det deployat.

4. Inaktivera produktions source maps Dina *.map-filer är debuggningsguld för dig—och för angripare. De flesta plattformar har en toggle. Slå av den innan lansering.

5. Lägg till dina Open Graph-metadata Som minimum: og:title, og:description, og:image. Din lanseringspost förtjänar att se bra ut i en tidslinje.

6. Generera en sitemap.xml Din framtida SEO-själv kommer att tacka dig. De flesta plattformar autogenererar dessa—kolla om din gjorde det.

Den större bilden

Här är min syn: vibe coding är inte problemet. Problemet är gapet mellan "det funkar på min maskin" och "det är produktionsklart". Traditionella utvecklare lärde sig det här gapet genom år av smärtsamma deployments. Vibe coders lär sig det snabbare—vilket faktiskt är bra.

Plattformarna förbättras. Standardvärdena blir bättre. Men tills säkerhetshärdning är lika automatiskt som SSL-certifikat, ligger ansvaret på oss som byggare att lägga till den där femminuterschecklistan före lansering.

Hastigheten i vibe coding är en superkraft. Säkerhet behöver inte vara skatten du betalar för att använda den.

Vad är din säkerhetsrutin före lansering? Lämna dina checklisttillägg i kommentarerna—jag letar alltid efter sätt att förbättra min.