Skrytý bezpečnostní dluh vibe-coded aplikací: Co odhalilo 155 spuštění
Past na rychlost aneb Co za sebou nechává vibe coding
Musíme si přiznat pravdu – všichni jsme to udělali. Strávili odpoledne s Lovable, Bolt nebo Cursor a do večeře měli živou URL adresu. Přišlo to jako kouzlo. Platforma se postarala o hosting, SSL fungovalo automaticky a náš malý vedlejší projekt najednou existoval.
Ale tady je ta nepříjemná pravda, ke které se pořád vracím: rychlé nasazení neznamená bezpečné nasazení. A jako někdo, kdo sleduje vibe coding revoluci, si myslím, že bychom měli mluvit o tom, co ta pipeline odpoledne → URL vlastně zanechává.
Jedna nedávná analýza prošla 155 vibe-coded aplikací, které jejich tvůrci veřejně spustili. Devětadevadesát jich bylo stále online a skenovatelných. Výsledky? Stejně povzbudivé jako znepokojivé – a měly by změnit způsob, jakým přemýšlíme o předstartovních kontrolách.
Dobrá zpráva: Tajemství zůstávají skrytá
Tady je něco, co mě mile překvapilo: pouhá 1 % skenovaných aplikací vykreslovala skutečné tajné klíče do prohlížeče.
Žádné odhalené OpenAI klíče, které pálí cizí rozpočet. Žádné AWS přihlašovací údaje plovoucí v klientském JavaScriptu. Žádné živé Stripe klíče připravené vykrást účet.
To mi říká něco důležitého: moderní AI coding platformy skutečně zlepšily své výchozí nastavení. Když vytvoříte nový projekt v Boltu nebo Replitu, platforma vás vede k edge functions pro tajnosti místo jejich vhození do browserového bundlu. To je upřímně dobrý UX design pro bezpečnost.
Ale jedno procento je pořád příliš mnoho. Jeden odhalený klíč znamená účet 50 000 korun od OpenAI, kompromitovaný AWS účet nebo Stripe spor, který potopí váš startup dřív, než začne. Nebuďte tou jednou procentou.
Supabase problém, o kterém nikdo nemluví
Tady to začíná být opravdu zapeklité.
37 % živých vibe-coded aplikací obsahuje Supabase anonymous key v kódu frontendu. A než začnete panikařit – to je vlastně očekávané. Supabase je takhle navržený. Anon key je určen k tomu být veřejný; vaše datová bezpečnost má přijít z Row Level Security (RLS) politik.
Tady je ten problém: RLS je opt-in. Tabulky začínají plně otevřené. A když v 11 večer codingujete a snažíte se stihnout launch deadline, je překvapivě snadné na ten checkbox zapomenout.
Každá tabulka s vypnutým RLS – nebo horší, líný using (true) – je dokořán otevřená dveře pro kohokoli s tím veřejným anon key. Útočník nemusí nic hackovat. Prostě... se dotazuje vaší databáze, protože jste zapomněli jedno nastavení.
Nemůžu dostatečně zdůraznit: pasivní skenování nemůže detekovat špatné RLS konfigurace. Scanner vidí jen frontend. Zranitelnost žije ve vaší databázi. Musíte to zkontrolovat ručně, tabulku po tabulce, než začnete.
Stejná rada platí pro Firebase (která se objevila ve 4 % skenovaných aplikací). Security rules nejsou volitelné doplňky. Jsou to celý bezpečnostní model.
Security headers: Neviditelný to-do list
Jestli jste nikdy nepřemýšleli o HTTP security headers, nejste sami. 91 % skenovaných aplikací nemá Content-Security-Policy a 88 % se dá vložit do iframe na jakékoli webové stránce (čau, clickjacking).
Nejsou to exotické zranitelnosti. Jsou to standardní hardenovací kroky, které jsou best practice už roky. Vibe coding pipeline je prostě... nezahrnuje defaultně.
Tady je rozbor ze scanu:
- 91 % chybí Content-Security-Policy
- 88 % chybí X-Frame-Options / frame-ancestors
- 37 % chybí X-Content-Type-Options
- 38 % chybí Referrer-Policy
- 8 % chybí Strict-Transport-Security
- Pouze 5 % mělo všechny security headers nakonfigurované
Světlá stránka? Hosting platformy řeší HSTS automaticky, takže tohle je většinou v pořádku. Ale ta díra v CSP je významná. Když AI-napsaná komponenta renderuje user-generated obsah nebo integruje third-party scripty, CSP je vaše poslední linie obrany. Bez ní se XSS útoky nemají kde schovat.
Launch polish gap
Tady je zjištění, u kterého jsem nečekal, že mě bude zajímat, ale naprosto ano: 30 % vibe-coded aplikací startuje bez Open Graph tagů.
To znamená, že když někdo sdílí váš produkt na X (Twitter), Discordu nebo Linkedinu, ukáže se to jako holá URL bez náhledového obrázku, bez titulku, bez popisu. Prostě... text. V roce 2024 to vypadá amatérsky a zabíjí click-through rates.
Další launch-day přešlapy nalezené ve scanu:
- 11 % nemělo meta description
- 77 % nemělo sitemap.xml
- Celkové bezpečnostní známky průměrně B-minus (84/100), pouze 13 % dostalo A
Aplikace nebyly katastrofy – prostě potřebovaly vyleštění. Ta samá rychlost, která vás dostane k launch, je ta, která vám nechá zapomenout <meta property="og:title">.
Moje 5minutová předlaunch checklist
Poté, co jsem prošel ten výzkum, aktualizoval jsem svůj osobní launch checklist. Tady je to, co opravdu záleží, než zveřejníte ten Show HN thread:
1. Prohledej bundle kvůli tajnostem
Prohledejte svůj build output pro sk-, sk_live_, service_role, ghp_. Cokoliv, co odpovídá, okamžitě rotujte a přesuňte do edge function nebo environment proměnné. Jeden odhalený klíč stačí.
2. Projeďte každou Supabase nebo Firebase tabulku
Otevřete dashboard. Každá veřejná tabulka potřebuje RLS. Každá politika potřebuje být specifická – nikdy using (true). Read access k jedné špatně nakonfigurované tabulce může odhalit celou uživatelskou databázi.
3. Přidejte tyto security headers
Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Začněte s Content-Security-Policy-Report-Only pokud chcete testovat bez enforcmentu. Ale dostanťe to do deploymentu.
4. Vypněte production source maps
Vaše *.map soubory jsou debugovací zlato pro vás – a pro útočníky. Většina platforem má toggle. Přepněte to před launchem.
5. Přidejte Open Graph metadata
Minimum: og:title, og:description, og:image. Váš launch post si zaslouží vypadat dobře v timeline.
6. Vygenerujte sitemap.xml Váś budoucí SEOJá vám poděkuje. Většina platforem to generuje automaticky – zkontrolujte, jestli to vaše udělalo.
Větší obrázek
Tady je můj pohled: vibe coding není problém. Problém je ta mezera mezi "funguje to na mém počítači" a "je to production-ready". Tradicionální vývojáři se tu mezeru naučili přes roky bolestivých deploymentů. Vibe coders se ji učí rychleji – což je ve skutečnosti dobré.
Platformy se zlepšují. Výchozí nastavení jsou lepší. Ale dokud security hardening není tak automatický jako SSL certifikáty, odpovědnost leží na nás jako builderech přidat ten pětiminutový checklist před launchem.
Rychlost vibe coding je superschopnost. Bezpečnost nemusí být daň, kterou za ni platíte.
Jaký je váš předlaunch bezpečnostní rituál? Napište své checklist doplňky do komentářů – vždycky hledám, jak zlepšit ten svůj.