Sikkerhetsfallgruvene i AI-drevet utvikling

La meg være ærlig: vi har alle vært der. Bruker formiddagen på å prompta Lovable, Bolt eller Cursor, og før middag har man en live URL. Det føles magisk. Platformen tar seg av hosting, SSL er automagisk, og prosjektet man har rotet sammen er plutselig ekte.

Men her er sannheten jeg stadig kommer tilbake til: å shippe raskt betyr ikke å shippe sikkert. Og som noen som har fulgt med på "vibe coding"-revolusjonen, tror jeg vi trenger å snakke om hva den der pipeline-en faktisk etterlater seg.

En nylig undersøkelse skannet 155 vibe-codete applikasjoner som ble lansert offentlig. Nitti-ni var fortsatt live og skannbare. Resultatene? Både oppmuntrende og bekymringsfulle—og de bør endre hvordan vi tenker på sjekklisten før lansering.

Den gode nyheten: Hemmeligheter holder seg faktisk skjult

Her var det som overrasket meg positivt: kun 1% av de skannede appene lekket faktiske secret keys til nettleseren.

Ingen eksponerte OpenAI API-nøkler som brenner opp noen andres budsjett. Ingen AWS-pålogginger som flyter rundt i klient-side JavaScript. Ingen Stripe live-nøkler klare til å tømme en bankkonto.

Dette forteller meg noe viktig: dagens AI-kodeplattformer har virkelig forbedret standardinnstillingene sine. Når du oppretter et nytt prosjekt i Bolt eller Replit, blir du veiledet mot edge functions for hemmeligheter i stedet for å dumpe dem i nettleser-bundelet. Det er genuin god UX-design for sikkerhet.

Men én prosent er fortsatt én for mye. Én eksponert nøkkel er en OpenAI-regning på 50 000 kroner, en kompromittert AWS-konto, eller en Stripe-tvist som sender startupen din i graven før den kommer i gang. Vær ikke den ene prosenten.

Supabase-problemet ingen snakker om

Her er det som blir skikkelig tricky.

37% av live vibe-codete apper har en Supabase anonymous key i frontend-koden. Og før du får panikk—det er faktisk forventet. Supabase er designet slik. Anon-nøkkelen er ment å være offentlig; sikkerheten til dataene dine skal komme fra Row Level Security (RLS)-policyer.

Her er problemet: RLS er opt-in. Tabeller starter fullstendig åpne. Og når du sitter og vibe-coder klokken 23:00, i full fart for å rekke lanseringsfristen, er det bemerkelsesverdig lett å gå glipp av den checkboxen.

Hver tabell med RLS deaktivert—eller verre, en lat using (true)-policy—er en dør på vid vei for alle med den offentlige anon-nøkkelen. En angriper trenger ikke å hacke noe. De trenger bare å spørre databasen din, fordi du glemte én innstilling.

Jeg kan ikke understreke dette nok: passiv skanning kan ikke oppdage RLS-feilkonfigureringer. Skanneren ser bare frontenden. Sårbarheten lever i databasen din. Du må sjekke dette manuelt, tabell for tabell, før du går live.

Samme råd gjelder Firebase (som dukket opp i 4% av de skannede appene). Security rules er ikke valgfrie tillegg. De er hele sikkerhetsmodellen.

Sikkerhetsheadere: Den usynlige to-do-listen

Hvis du aldri har tenkt på HTTP-sikkerhetsheadere, er du ikke alene. 91% av de skannede appene mangler Content-Security-Policy, og 88% kan bygges inn i iframes på hvilken som helst nettside (hei, clickjacking).

Dette er ikke eksotiske sårbarheter. Det er standard herdingstrinn som har vært best practice i år. Vibe coding-pipelinen inkluderer dem bare ikke som standard.

Her er oversikten fra skanningen:

• 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% hadde alle sikkerhetsheadere konfigurert

Det positive? Hosting-plattformer håndterer HSTS automatisk, så det er stort sett dekket. Men CSP-gapen er betydelig. Når en AI-skrive komponent rendrer brukergenerert innhold eller integrerer tredjepartsskript, er en CSP din siste forsvarslinje. Uten én har XSS-angrep ingen plass å gjemme seg.

Lanseringspolish-gropen

Her er et funn jeg ikke forventet å bry meg om, men absolutt gjør: 30% av vibe-codete apper lanserer uten Open Graph-tagger.

Det betyr at når noen deler produktet ditt på X (Twitter), Discord eller LinkedIn, vises det som en naken URL uten forhåndsvisningsbilde, ingen tittel, ingen beskrivelse. Bare... tekst. I 2024 ser det amatørmessig ut og dreper click-through-raten.

Ytterligere oversikter funnet i skanningen:

• 11% hadde ingen meta description
• 77% hadde ingen sitemap.xml
• Totale sikkerhetskarakterer var i gjennomsnitt B-minus (84/100), med kun 13% som fikk en A

Appene var ikke katastrofer—de trengte bare polering. Den samme hastigheten som får deg til lansering er den samme hastigheten som får deg til å glemme <meta property="og:title">.

Min 5-minutters sjekkliste før lansering

Etter å ha lest gjennom denne forskningen har jeg oppdatert min personlige lanseringssjekkliste. Her er hva som faktisk betyr noe før du poster den der Show HN-tråden:

1. Jakte på secrets i pakken din

Søk i det bygde resultatet etter sk-, sk_live_, service_role, ghp_. Alt som matcher roteres umiddelbart og flyttes til en edge function eller environment variable. Én eksponert nøkkel er alt som skal til.

2. Revider hver Supabase- eller Firebase-tabell

Åpne dashboarden din. Hver offentlig tabell trenger RLS aktivert. Hver policy trenger å være spesifikk—aldri using (true). Lesetilgang til én feilkonfigurert tabell kan eksponere hele brukerdatabasen din.

3. Legg til disse sikkerhetsheaderene

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 uten håndhevelse. Men få det deployet.

4. Deaktiver produksjons-source maps

*.map-filene dine er debuggingsgull for deg—og for angripere. De fleste plattformer har en bryter. Slå den av før lansering.

5. Legg til Open Graph-metadata

Minimum: og:title, og:description, og:image. Lanseringsposten din fortjener å se bra ut i en tidslinje.

6. Generer en sitemap.xml

Fremtidige SEO-deg vil sette pris på det. De fleste plattformer autogenererer disse—sjekk om din gjorde det.

Det store bildet

Her er min take: vibe coding er ikke problemet. Problemet er gapet mellom "det funker på maskinen min" og "det er produksjonsklart". Tradisjonelle utviklere lærte dette gapet gjennom år med smertefulle deploys. Vibe kodere lærer det fortere—og det er faktisk bra.

Plattformene blir bedre. Standardinnstillingene blir bedre. Men inntil sikkerhetsherding er like automagisk som SSL-sertifikater, faller ansvaret på oss som byggere å legge til den fem-minutters sjekklisten før lansering.

Hastigheten til vibe coding er en superkraft. Sikkerhet trenger ikke være avgiften du betaler for å bruke den.

Hva er din før-lansering sikkerhetsrutine? Legg til sjekklisten din i kommentarene—jeg er alltid på jakt etter forbedringer.