Capcana de Viteză din Dezvoltarea AI

Să fim sinceri — cu toții am făcut-o. Stai o după-amiază întreagă dând prompt-uri pe Lovable, Bolt sau Cursor, și până la cină ai un URL live. Se simte ca magia. Platforma s-a ocupat de hosting, SSL a venit automat, iar proiectul tău secundar e brusc real.

Dar iată adevărul inconfortabil la care revin constant: viteza de livrare nu înseamnă siguranță. Și ca observator al revoluției vibe coding, cred că ar trebui să vorbim despre ce lasă în urmă acel pipeline de la după-amiază la URL.

Un studiu recent a scanat 155 de aplicații vibe-coded lansate public. Nouăzeci și nouă erau încă live și scanabile. Rezultatele? Egal parte încurajator și îngrijorător — și ar trebui să schimbe cum gândim checklist-urile de pre-lansare.

Veștile Bune: Secretele Rămân Ascunse

Ceea ce m-a surprins plăcut: doar 1% din aplicațiile scanate aveau secret keys expuse în browser.

Niciun OpenAI API key expus care arde bugetul altcuiva. Niciun credential AWS plutind în JavaScript-ul client-side. Niciun Stripe live key gata să golească un cont.

Asta îmi spune ceva important: platformele moderne de coding AI chiar și-au îmbunătățit default-urile. Când creezi un proiect nou în Bolt sau Replit, platforma te ghidează spre edge functions pentru secrets în loc să le arunce în bundle-ul browserului. Asta e design UX pentru securitate, într-adevăr.

Dar un la sută e încă prea mult. Un singur key expus poate însemna o factură OpenAI de 50.000 de dolari, un cont AWS compromis, sau un dispute Stripe care îți îngroapă startup-ul înainte să înceapă. Nu fi acel un la sută.

Problema Supabase de Care Nimeni Nu Vorbește

Aici lucrurile devin cu adevărat delicate.

37% din aplicațiile vibe-coded live includ o cheie anon Supabase în codul frontend. Și înainte să intri în panică — asta e de așteptat. Supabase e proiectat să funcționeze așa. Anon key-ul e menit să fie public; securitatea datelor tale vine din politicile Row Level Security (RLS).

Iată problema: RLS este opt-in. Tabelele încep complet deschise. Și când faci vibe coding la 11 noaptea, cu deadline-ul de lansare aproape, e surprinzător de ușor să ratezi acel checkbox.

Fiecare tabel cu RLS dezactivat — sau mai rău, un using (true) leneș — e o ușă deschisă larg oricui are acel anon key public. Un atacator nu trebuie să spargă nimic. Doar interoghează baza ta de date, pentru că ai uitat o setare.

Nu pot sublinia suficient: scanarea pasivă nu poate detecta misconfigurările RLS. Scannerul vede doar frontend-ul. Vulnerabilitatea stă în baza ta de date. Trebuie să verifici manual, tabel cu tabel, înainte să faci live.

Același sfat se aplică și la Firebase (care a apărut în 4% din aplicații). Security rules nu sunt add-ons opționale. Sunt întregul model de securitate.

Headerele de Securitate: Lista de To-Do Invizibilă

Dacă nu te-ai gândit niciodată la HTTP security headers, nu ești singur. 91% din aplicații nu au Content-Security-Policy, iar 88% pot fi embed-uite în iframe-uri de pe orice site (salut, clickjacking).

Nu sunt vulnerabilități exotice. Sunt pași standard de hardening care au fost best practice de ani buni. Pipeline-ul vibe coding pur și simplu... nu le include by default.

Iată breakdown-ul din scanare:

• 91% lipsă Content-Security-Policy
• 88% lipsă X-Frame-Options / frame-ancestors
• 37% lipsă X-Content-Type-Options
• 38% lipsă Referrer-Policy
• 8% lipsă Strict-Transport-Security
• Doar 5% aveau toate headerele de securitate configurate

Partea bună? Platformele de hosting gestionează HSTS automat, deci asta e acoperită în mare. Dar gap-ul CSP e semnificativ. Când o componentă scrisă de AI randerează conținut generat de utilizatori sau integrează scripturi third-party, un CSP e ultima ta linie de apărare. Fără el, atacurile XSS n-au unde să se ascundă.

Gap-ul de Polish la Lansare

Iată o descoperire la care nu mă așteptam să țin, dar o fac complet: 30% din aplicațiile vibe-coded lansări fără Open Graph tags.

Asta înseamnă că when someone shares your product on X (Twitter), Discord sau LinkedIn, apare ca un URL gol fără preview image, fără titlu, fără descriere. Doar... text. În 2024, asta arată amator și ucide click-through rates.

Alte oversight-uri de ziua lansării găsite în scanare:

• 11% nu aveau meta description
• 77% nu aveau sitemap.xml
• Notele medii de securitate au fost B-minus (84/100), cu doar 13% câștigând un A

Aplicațiile nu erau dezastre — aveau doar nevoie de polish. Aceeași viteză care te duce la launch e aceeași viteză care te face să uiți <meta property="og:title">.

Checklist-ul Meu de 5 Minute Pre-Lansare

După ce am citit cercetarea asta, mi-am actualizat checklist-ul personal de lansare. Iată ce contează cu adevărat înainte să postezi acel thread Show HN:

1. Vânează secrets în bundle-ul tău

Caută în output-ul build-uit pentru sk-, sk_live_, service_role, ghp_. Orice se potrivește merge rotit imediat și mutat într-o edge function sau environment variable. Un singur key expus e de ajuns.

2. Audit-ează fiecare tabel Supabase sau Firebase

Deschide dashboard-ul. Fiecare tabel public are nevoie de RLS activat. Fiecare policy trebuie să fie specifică — niciodată using (true). Accesul de citire la un singur tabel misconceput poate expune întreaga bază de date de utilizatori.

3. Adaugă aceste security headers

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

Începe cu Content-Security-Policy-Report-Only dacă vrei să testezi fără enforcement. Dar publică-l.

4. Dezactivează source maps-urile din producție

Fișierele tale *.map sunt aur pentru debugging — și pentru atacatori. Majoritatea platformelor au un toggle. Întoarce-l off înainte de launch.

5. Adaugă metadata Open Graph

Minimum: og:title, og:description, og:image. Postarea ta de lansare merită să arate bine într-un timeline.

6. Generează un sitemap.xml

Viitorul tău SEO self va mulțumi. Majoritatea platformelor le generează automat — verifică dacă a ta a făcut-o.

Imaginea de Ansamblu

Iată ce cred: vibe coding nu e problema. Problema e gap-ul dintre "funcționează pe mașina mea" și "e production-ready". Dezvoltatorii tradiționali au învățat acest gap prin ani de deployment-uri dureroase. Vibe coderii îl învață mai rapid — ceea ce e de fapt bine.

Platformele se îmbunătățesc. Default-urile devin mai bune. Dar până când security hardening nu e la fel de automat ca certificatele SSL, responsabilitatea cade pe noi, builderii, să adăugăm acel checklist de cinci minute înainte de launch.

Viteza vibe coding-ului e un superputer. Securitatea nu trebuie să fie taxa pe care o plătești pentru ea.

Care e rutina ta de securitate pre-lansare? Lasă adăugările tale la checklist în comentarii — caut mereu să-mi îmbunătățesc.