Vibe-koodauksen nopeusansan varjopuoli

Olemme kaikki tehneet sen. Istuneet iltapäivän LOVella, Boltilla tai Cursorilla, ja illalliseksi mokoma osoitteessa pyöri jo toimiva sovellus. tuntui maagiselta. Hostaus hoidettiin automaattisesti, SSL toimi heti, ja pieni sivuprojektimme oli yhtäkkiä totista totta.

Mutta tässä on se ikävä totuus, johon palaan yhä uudestaan: nopea julkaisu ei tarkoita turvallista julkaisua. Ja kun olen seurannut tätä nopean AI-kehityksen aaltoa, on korkea aika puhua siitä, mitä tuo iltapäivästä-lanseeraukseen -putki oikeasti jättää huomiotta.

Tuoreessa tutkimuksessa skannattiin 155 julkisesti lanseerattua vibe-koodattua sovellusta. Niistä 99 oli edelleen elossa ja skannattavissa. Tulokset? Yhtä aikaa rohkaisevia ja huolestuttavia – ja ne muuttavat tapaa, jolla meidän tulisi ajatella esilanseerauslistoja.

Hyvät uutiset: Salaisuudet pysyvät piilossa

Tämä yllätti minut positiivisesti: vain prosentti skannatuista sovelluksista vuoti varsinaisia salaisia avaimia selaimelle.

Ei paljastuneita OpenAI-avaimia, jotka polttivat jonkun toisen budjettia. Ei AWS-tunnuksia client-side JavaScriptissä. Ei Stripe-liveavaimia valmiina tyhjentämään tiliä.

Tämä kertoo jotain tärkeää: modernit AI-koodausalustat ovat todella parantaneet oletusasetuksiaan. Kun luot uuden projektin Bolttiin tai Replitiin, alusta ohjaa sinua kohti edge-funktioita salaisuuksille sen sijaan, että ne dumpattaisiin suoraan selaimelle. Se on aitoa hyvää UX-suunnittelua turvallisuuden näkökulmasta.

Mutta yksi prosentti on edelleen yksi prosentti liikaa. Yksi paljastunut avain voi tarkoittaa 50 000 euron OpenAI-laskua, kompromettoitunutta AWS-tiliä tai Stripe-kiistaa, joka upottaa startupin ennen kuin se ehtii edes alkaa.

Supabase-ongelma, josta kukaan ei puhu

Tässä kohtaa asiat menevät toden teolla mutkikkaiksi.

37 % elossa olevista vibe-koodatuista sovelluksista sisältää Supabase-anonüümkäyttöavaimen frontend-koodissaan. Ja ennen kuin panikoit – se on oikeastaan odotettua. Supabase on suunniteltu näin. Anon-avain on tarkoitus olla julkinen; tietoturvan pitäisi tulla Row Level Security (RLS) -käytännöistä.

Tässä on ongelma: RLS on opt-in. Taulukot ovat aluksi täysin avoimia. Ja kun vibe-koodaat kello 23:een asti ja jahtaat lanseerausdeadlinea, on huikean helppoa ohittaa se yksi checkboxi.

Jokainen taulukko, jossa RLS on disabloitu – tai vielä pahempaa, laiska using (true) -käytäntö – on ovi selkosalilla kenelle tahansa, jolla on tuo julkinen anon-avain. Hyökkääjän ei tarvitse murtautua mihinkään. Hän vain kyselee tietokantaa, koska sinä unohdit yhden asetuksen.

En voi tarpeeksi korostaa: passiivinen skannaus ei voi havaita RLS-virhekonfiguraatioita. Skanneri näkee vain frontendin. Haavoittuvuus asuu tietokannassasi. Sinun täytyy tarkistaa tämä käsin, taulukko taulukolta, ennen lanseerausta.

Sama neuvo pätee Firebaseen (joka näkyi 4 %:ssa skannatuista sovelluksista). Turvallisuussäännöt eivät ole valinnaisia lisäosia. Ne ovat koko turvallisuusmalli.

Turvallisuusheaderit: Näkymätön tehtävälista

Jos et ole koskaan ajatellut HTTP-turvallisuusheadereita, et ole yksin. 91 % skannatuista sovelluksista puuttuu Content-Security-Policy, ja 88 % voidaan upottaa iframeskehyksiin mistä tahansa sivustosta (terve, napsautuskaappaus).

Nämä eivät ole eksoottisia haavoittuvuuksia. Ne ovat standardeja koventamistoimenpiteitä, jotka ovat olleet parhaita käytäntöjä vuosia. Vibe-koodausputki ei vain sisällä niitä oletuksena.

Tässä skannauksen erittely:

• 91 % puuttuu Content-Security-Policy
• 88 % puuttuu X-Frame-Options / frame-ancestors
• 37 % puuttuu X-Content-Type-Options
• 38 % puuttuu Referrer-Policy
• 8 % puuttuu Strict-Transport-Security
• Vain 5 %:lla oli kaikki turvallisuusheaderit konfiguroitu

Valoisa puoli? Hostausalustat hoitavat HSTS:n automaattisesti, joten se on pääosin kunnossa. Mutta CSP-aukko on merkittävä. Kun AI-kirjoitettu komponentti renderöi käyttäjän luomaa sisältöä tai integroi kolmannen osapuolen skriptejä, CSP on viimeinen puolustuslinja. Ilman sitä XSS-hyökkäyksillä ei ole minne piiloutua.

Lanseerauskiillotuksen puute

Tämä löydös yllätti minut: 30 % vibe-koodatuista sovelluksista lanseerataan ilman Open Graph -tageja.

Se tarkoittaa, että kun joku jakaa tuotteesi X:ssä (Twitter), Discordissa tai LinkedInissä, se näkyy paljaana URL-osoitteena ilman esikatselukuvaa, otsikkoa tai kuvausta. Vain... tekstiä. Vuonna 2024 se näyttää amatöörimäiseltä ja tappaa klikkausprosentit.

Lanseerauspäivän muita huolimattomuuksia skannauksessa:

• 11 %:lla ei ollut meta-kuvausta
• 77 %:lla ei ollut sitemap.xml:ää
• Keskimääräinen turvaluokitus oli B-miinus (84/100), ja vain 13 % ansaitsi A:n

Sovellukset eivät olleet katastrofeja – ne vain kaipasivat kiillotusta. Sama nopeus, joka vie lanseeraukseen, on sama nopeus, joka заставляет unohtaa <meta property="og:title">.

Viiden minuutin esilanseerauslista

Tämän tutkimuksen jälkeen olen päivittänyt omaa lanseerauslistaani. Tässä on ne asiat, jotka oikeasti merkitsevät ennen kuin julkaiset sen Show HN -ketjun:

1. Metsästä salaisuuksia bundle-sta Etsi rakennetusta outputista sk-, sk_live_, service_role, ghp_. Kaikki mikä täsmää, pitää rotatoida välittömästi ja siirtää edge-funktioon tai ympäristömuuttujaan. Yksi paljastunut avain riittää.

2. Tarkista jokainen Supabase- tai Firebase-taulukko Avaa hallintapaneeli. Jokainen julkinen taulukko tarvitsee RLS:n päälle. Jokainen käytäntö pitää olla tarkka – ei koskaan using (true). Lukuoikeus yhteen väärin konfiguroituun taulukkoon voi paljastaa koko käyttäjätietokannan.

3. Lisää nämä turvallisuusheaderit

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

Aloita Content-Security-Policy-Report-Only:lla, jos haluat testata ilman pakottamista. Mutta deploya se.

4. Disabloi production-sourcemapit *.map-tiedostot ovat debuggauksen kultaa sinulle – ja hyökkääjille. Useimmissa alustoissa on toggle. Napsauta se pois ennen lanseerausta.

5. Lisää Open Graph -metadata Minimissään: og:title, og:description, og:image. Lanseerauspostauksesi ansaitsee näyttää hyvältä aikajanalla.

6. Generoi sitemap.xml SEO-tulevaisuuden minäsi kiittää. Useimmat alustat generoivat nämä automaattisesti – tarkista, tekiikö sinun alustasi niin.

Isompi kuva

Tässä on näkemykseni: vibe-koodaus ei ole ongelma. Ongelma on kuilu "se toimii omalla koneellani" ja "se on tuotantokelpoinen" välillä. Perinteiset kehittäjät oppivat tämän kuilun vuosien kivuliaiden deploymentejen kautta. Vibe-koodaajat oppivat sen nopeammin – mikä on oikeastaan hyvä juttu.

Alustat kehittyvät. Oletusasetukset paranevat. Mutta kunnes turvallisuuden koventaminen on yhtä automaattista kuin SSL-varmenteet, vastuu on meillä rakentajilla lisätä se viiden minuutin lista ennen lanseerausta.

Vibe-koodauksen nopeus on supervoima. Tietoturvan ei tarvitse olla hinta, jonka maksat sen käytöstä.

Mikä on sinun esilanseerausturvallisuusrutiinisi? Jätä listalisäyksesi kommentteihin – etsin aina tapoja parantaa omaani.