La Trappola della Velocità nello Sviluppo AI-Powered

Siamo onesti: l'abbiamo fatto tutti. Una sera a ninjare su Lovable, Bolt o Cursor, e a cena avevamo un URL funzionante. Sembrava magia. Hosting gestito, SSL automatico, il nostro side project improvvisamente reale.

Ma la verità che continuo a rivedere è questa: andare veloci non significa andare sicuri. E osservando la rivoluzione del vibe coding da vicino, credo sia il momento di parlare di cosa resta davvero in camino quella scorciatoia dal pomeriggio al URL in produzione.

Una ricerca recente ha scannerizzato 155 applicazioni vibe-coded pubblicate dai loro creatori. Novantanove erano ancora live e accessibili. I risultati? Equally encouraging and concerning—e dovrebbero cambiare il modo in cui pensiamo alla lista pre-lancio.

La Buona Notizia: i Secret Restano Nascosti

Quello che mi ha piacevolmente sorpreso: solo l'1% delle app scannerizzate ha esposto chiavi segrete al browser.

Niente OpenAI API key che bruciano il budget di qualcun altro. Niente credenziali AWS in chiaro nel JavaScript client-side. Niente Stripe live key pronte a svuotare un conto.

Questo mi dice qualcosa di importante: le piattaforme AI di sviluppo moderne hanno davvero migliorato i loro default. Quando crei un progetto in Bolt o Replit, ti guidano verso edge functions per i secret invece di buttarli nel bundle browser. È un design UX per la sicurezza che funziona.

Ma l'1% è comunque uno in troppo. Una chiave esposta può significare un conto OpenAI da 50.000 dollari, un account AWS compromesso, o una disputa Stripe che affonda la tua startup prima ancora di iniziare. Non essere tu quello.

Il Problema Supabase che Nessuno Tocca

Qui le cose si fanno più complicate.

Il 37% delle app vibe-coded live include una Supabase anonymous key nel codice frontend. E prima che tu entri in panico—questo è in realtà previsto. Supabase è progettato così. L'anon key è pensata per essere pubblica; la sicurezza dei dati dovrebbe arrivare dalle policy Row Level Security (RLS).

Ecco il problema: RLS è opt-in. Le tabelle partono completamente aperte. E quando stai vibe coding alle 23, in corsa per la deadline del lancio, è terribilmente facile perdersi quella checkbox.

Ogni tabella con RLS disabilitato—o peggio, una policy using (true) messa lì per pigrizia—è una porta spalancata a chiunque abbia quella anon key pubblica. Un attacker non deve hackerare nulla. Deve solo... interrogare il tuo database, perché tu hai dimenticato un'impostazione.

Non posso stressarlo abbastanza: lo scanning passivo non può detectare misconfigurazioni RLS. Lo scanner vede solo il frontend. La vulnerabilità vive nel tuo database. Devi controllare manualmente, tabella per tabella, prima di andare live.

Lo stesso discorso vale per Firebase (presente nel 4% delle app scannerizzate). Le security rules non sono optional—sono tutto il tuo modello di sicurezza.

Security Headers: la Lista Invisibile

Se non hai mai pensato agli HTTP security headers, non sei solo. Il 91% delle app scannerizzate non ha una Content-Security-Policy, e l'88% può essere embedded in iframe da qualsiasi sito (ciao clickjacking).

Non sono vulnerabilità esotiche. Sono hardening standard che sono best practice da anni. Il pipeline vibe coding semplicemente... non li include di default.

Ecco il breakdown:

• 91% senza Content-Security-Policy
• 88% senza X-Frame-Options / frame-ancestors
• 37% senza X-Content-Type-Options
• 38% senza Referrer-Policy
• 8% senza Strict-Transport-Security
• Solo il 5% aveva tutti i security header configurati

Il lato positivo? Le piattaforme di hosting gestiscono HSTS automaticamente, quindi quello è coperto quasi ovunque. Ma il gap CSP è significativo. Quando un componente scritto da AI renderizza user-generated content o integra script di terze parti, una CSP è la tua ultima linea di difesa. Senza, gli attacchi XSS non hanno dove nascondersi.

Il Divario della Finitura pre-Lancio

Ecco un finding che non mi aspettavo di trovarmi a curare, ma che ora mi importa tantissimo: il 30% delle app vibe-coded lanciano senza Open Graph tags.

Questo significa che quando qualcuno condivide il tuo prodotto su X (Twitter), Discord o LinkedIn, appare come un URL nudo senza preview image, senza titolo, senza descrizione. Solo... testo. Nel 2024, questo fa amateur e uccide i click-through rates.

Altri oversight da giorno di lancio trovati nella scansione:

• 11% senza meta description
• 77% senza sitemap.xml
• Voto medio sicurezza B-meno (84/100), con solo il 13% che prende la A

Le app non erano disastri—avevano solo bisogno di lucidatura. La stessa velocità che ti porta al lancio è quella che ti fa dimenticare <meta property="og:title">.

La Mia Checklist Pre-Lancio da 5 Minuti

Dopo aver letto questa ricerca, ho aggiornato la mia checklist personale di lancio. Ecco cosa conta davvero prima di postare quel thread su Show HN:

1. Caccia ai secret nel bundle Cerca nel tuo built output per sk-, sk_live_, service_role, ghp_. Qualsiasi cosa matchi viene ruotata immediatamente e spostata in un'edge function o environment variable. Una chiave esposta è tutto quello che serve.

2. Audit di ogni tabella Supabase o Firebase Apri la dashboard. Ogni tabella pubblica ha bisogno di RLS abilitato. Ogni policy deve essere specifica—mai using (true). Read access a una tabella misconfigurata può esporre il tuo intero database utenti.

3. Aggiungi questi security header

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

Parti con Content-Security-Policy-Report-Only se vuoi testare senza enforcement. Ma mettilo in produzione.

4. Disabilita i source maps di produzione I tuoi file *.map sono oro per te—e per gli attacker. La maggior parte delle piattaforme ha un toggle. Giralo su off prima del lancio.

5. Aggiungi i tuoi Open Graph metadata Come minimo: og:title, og:description, og:image. Il tuo post di lancio merita di essere figo in timeline.

6. Genera sitemap.xml Il te stesso SEO del futuro ti ringrazierà. La maggior parte delle piattaforme li genera automaticamente—controlla se la tua l'ha fatto.

Il Quadro Più Grande

Ecco la mia: vibe coding non è il problema. Il problema è il gap tra "funziona sulla mia macchina" e "è production-ready". Gli sviluppatori tradizionali hanno imparato questo gap attraverso anni di deployment dolorosi. I vibe coder lo stanno imparando più velocemente—il che è in realtà un bene.

Le piattaforme stanno migliorando. I default stanno diventando più sicuri. Ma finché l'hardening della sicurezza non sarà automatico quanto i certificati SSL, la responsabilità ricade su di noi come builder di aggiungere quella checklist di cinque minuti prima del lancio.

La velocità del vibe coding è un superpotere. La sicurezza non deve essere la tassa che paghi per usarlo.

Cosa c'è nella tua routine di sicurezza pre-lancio? Condividi le aggiunte alla tua checklist nei commenti—sto sempre cercando di migliorare la mia.