Skyggerne bag AI-drevet Udvikling

Lad os være ærlige—vi har alle sammen gjort det. Brugt en eftermiddag på at prompte rundt i Lovable, Bolt eller Cursor, og ved aftensmadstid havde vi et live domain. Det føltes magisk. Platformen tog sig af hosting, SSL var automatisk, og vores lille sideprojekt var pludselig virkeligt.

Men her er den ubehagelige sandhed, jeg bliver ved med at vende tilbage til: hurtig lancering betyder ikke sikker lancering. Og som et menneske der har fulgt "vibe coding"-revolutionen tæt, tror jeg vi er nødt til at tale om, hvad den eftermiddag-til-URL pipeline egentlig efterlader.

En nylig undersøgelse scannede 155 vibe-kodede applikationer, som deres skabere havde lanceret offentligt. Nioghalvfems var stadig live og kunne scannes. Resultaterne? Lige dele opmuntrende og bekymrende—og de bør ændre den måde, vi tænker om tjeklister før lancering.

Den Gode Nyhed: Secrets Bliver Faktisk Gemt

Her er hvad der behageligt overraskede mig: kun 1% af de scannede apps lækkede faktiske secret keys til browseren.

Ingen eksponerede OpenAI API keys der brændte igennem nogens budget. Ingen AWS credentials der flød rundt i client-side JavaScript. Ingen Stripe live keys klar til at tømme en bankkonto.

Det fortæller mig noget vigtigt: de moderne AI kode-platforme har virkelig forbedret deres standardindstillinger. Når du opretter et nyt projekt i Bolt eller Replit, guider platformen dig mod edge functions til secrets i stedet for at dumpe dem i browser-bundtet. Det er genuint god UX design for sikkerhed.

Men én procent er stadig én for meget. Én eksponeret key er en regning på 50.000 kroner til OpenAI, en kompromitteret AWS-konto, eller en Stripe-disput der synker din startup før den overhovedet er kommet i gang. Vær ikke den én procent.

Supabase-problemet Ingen Taler Om

Her bliver det virkelig tricky.

37% af live vibe-kodede apps inkluderer en Supabase anonymous key i deres frontend kode. Og før du får panik—det er faktisk forventet. Supabase er designet sådan. Anon key'en er ment til at være offentlig; din datasikkerhed skal komme fra Row Level Security (RLS) policies.

Her er problemet: RLS er opt-in. Tabeller starter fuldt åbne. Og når du vibe coder klokken 23:00 og fører kapløb for at ramme din lanceringsdeadline, er detremarkabelt let at misser den checkbox.

Hver tabel med RLS deaktiveret—eller værre, en doven using (true) policy—er en dør vidt åben for enhver med den offentlige anon key. En angriber behøver ikke at hacke noget. De skal bare... query din database, fordi du glemte én indstilling.

Jeg kan ikke understrege nok: passiv scanning kan ikke detektere RLS miskonfigurationer. Scanneren ser kun frontenden. Sårbarheden bor i din database. Du er nødt til at tjekke dette manuelt, tabel for tabel, før du går live.

Samme råd gælder Firebase (som dukkede op i 4% af scannede apps). Security rules er ikke optionelle tilføjelser. De er hele sikkerhedsmodelen.

Security Headers: Den Usynlige To-Do Liste

Hvis du aldrig har tænkt over HTTP security headers, er du ikke alene. 91% af scannede apps mangler en Content-Security-Policy, og 88% kan embeddes i iframes på enhver hjemmeside (hej, clickjacking).

Dette er ikke esoteriske sårbarheder. Det er standard-hærdningstrin der har været best practice i årevis. Vibe coding pipelinen inkluderer dem bare... ikke som standard.

Her er opdelingen fra scanningen:

• 91% mangler Content-Security-Policy
• 88% mangler X-Frame-Options / frame-ancestors
• 37% mangler X-Content-Type-Options
• 38% mangler Referrer-Policy
• 8% mangler Strict-Transport-Security
• Kun 5% havde alle security headers konfigureret

Den positive vinkel? Hostingplatforme håndterer HSTS automatisk, så det er mestendels dækket. Men CSP-gabet er betydeligt. Når en AI-skrevet komponent renderer bruger-genereret indhold eller integrerer tredjeparts scripts, er en CSP din sidste forsvarslinje. Uden én har XSS-angreb ingen steder at gemme sig.

Lanceringens Poleringsgab

Her er et fund jeg ikke forventede at interessere mig for, men absolut gør: 30% af vibe-kodede apps lancerer uden Open Graph tags.

Det betyder at når nogen deler dit produkt på X (Twitter), Discord eller LinkedIn, vises det som en nøgen URL uden preview-billede, ingen titel, ingen beskrivelse. Bare... tekst. I 2024 ser det amatøragtigt ud og dræber click-through rates.

Yderligere lancerings-dags oversigter fundet i scanningen:

• 11% havde ingen meta description
• 77% havde ingen sitemap.xml
• Samlet sikkerhedsgrad i gennemsnit: B-minus (84/100), kun 13% fik et A

Apapperne var ikke katastrofer—de havde bare brug for polering. Den samme hastighed der får dig til lancering er den hastighed der får dig til at glemme <meta property="og:title">.

Min 5-Minutters Pre-Launch Tjekliste

Efter at have læst igennem denne forskning, har jeg opdateret min personlige lancerings-tjekliste. Her er hvad der faktisk betyder noget før du poster den Show HN-tråd:

1. Jag secrets i dit bundle

Søg i dit bygget output efter sk-, sk_live_, service_role, ghp_. Alt hvad der matcher bliver roteret øjeblikkeligt og flyttet til en edge function eller environment variable. Én eksponeret key er alt det tager.

2. Auditér hver Supabase eller Firebase tabel

Åbn dit dashboard. Hver offentlig tabel skal have RLS aktiveret. Hver policy skal være specifik—aldrig using (true). Læseadgang til én miskonfigureret tabel kan eksponere hele din brugerdatabase.

3. Tilføj disse security headers

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

Start med Content-Security-Policy-Report-Only hvis du vil teste uden håndhævelse. Men få det deployet.

4. Deaktiver produktions source maps

Dine *.map filer er debugging-guld for dig—og for angribere. De fleste platforme har en toggle. Slå den fra før lancering.

5. Tilføj din Open Graph metadata

Minimum: og:title, og:description, og:image. Din lancerings-post fortjener at se godt ud i et timeline.

6. Generér en sitemap.xml

Din fremtidige SEO-selv vil takke dig. De fleste platforme auto-genererer disse—tjek om din gjorde.

Det Større Billede

Her er min vinkel: vibe coding er ikke problemet. Problemet er gap'et mellem "det virker på min maskine" og "det er produktionsklar". Traditionelle udviklere lærte dette gap gennem år af smertefulde deployments. Vibe coders lærer det hurtigere—hvilket faktisk er godt.

Platformene forbedres. Standardindstillingerne bliver bedre. Men indtil sikkerhedshærdning er så automatisk som SSL certificates, ligger ansvaret på os som buildere for at tilføje den fem-minutters tjekliste før lancering.

Hastigheden af vibe coding er en superpower. Sikkerhed behøver ikke at være den pris du betaler for at bruge den.

Hvad er din pre-launch sikkerhedsrutine? Skriv dine tjekliste-tilføjelser i kommentarerne—jeg leder altid efter måder at forbedre min på.