Checklist di sicurezza per app Lovable: la Sua app è sicura?
Lovable, la piattaforma, e l'app che vi ha costruito sono protette separatamente. Lovable cerca gli errori comuni, ma la Sua app è sicura solo quanto le sue regole di accesso, le sue chiavi e il suo codice server. Verifichi che la row-level security sia attiva su ogni tabella esposta e corrisponda a chi può vedere cosa, che nessuna chiave segreta arrivi al browser, che i pagamenti siano confermati sul server e che qualcuno sorvegli l'app live.
- Dietro il CVE-2025-48757
- Row-level security disattivata, o troppo ampia
- Si può distribuire
- La chiave pubblicabile (anon) di Supabase
- Mai distribuire
- La chiave service role o altre chiavi segrete
- Ricontrollare
- Dopo ogni modifica che tocca dati o accessi
Lovable è sicuro, e questo rende sicura la mia app?
Lovable dichiara di supportare i requisiti SOC 2 e GDPR e pubblica la documentazione di sicurezza nel suo trust center. Questo riguarda la piattaforma di Lovable: la sua infrastruttura, i suoi controlli di accesso, il suo personale. Non riguarda le regole all'interno della Sua app, perché quelle le ha scritte Lei (con l'aiuto di Lovable).
La scansione di sicurezza di Lovable esegue un controllo rapido a ogni pubblicazione: una revisione del database, un audit delle dipendenze e un controllo del server MCP. Una scansione più approfondita, avviata a mano (o pianificata, per i clienti Lovable Enterprise), esamina anche controllo degli accessi, endpoint non autenticati, injection, segreti trapelati, pagamenti, autenticazione e dati personali esposti. La documentazione di Lovable è chiara: questi strumenti non possono garantire una sicurezza completa. Consideri la scansione un rilevatore di fumo, non un'ispezione.
Cos'era il CVE-2025-48757, e riguarda la mia app?
Il CVE-2025-48757, pubblicato a maggio 2025, descrive policy di row-level security insufficienti nei siti generati da Lovable fino al 15 aprile 2025, che permettevano ad attaccanti non autenticati di leggere o scrivere tabelle del database. Il National Vulnerability Database statunitense lo classifica con un punteggio CVSS 3.1 critico di 9,3 e segnala che Lovable lo contesta, sostenendo che ogni cliente è responsabile della protezione dei dati della propria app.
Il ricercatore che lo ha segnalato, Matt Palmer, dice di aver analizzato 1.645 progetti e trovato 303 endpoint vulnerabili in 170 di essi, e che Lovable ha introdotto la sua scansione di sicurezza con Lovable 2.0 ad aprile 2025. Qualunque opinione abbia sulla controversia, la lezione pratica è la stessa: se la Sua app è stata generata prima di allora, o se da allora ha modificato le tabelle, verifichi Lei stesso le policy. Una policy che esiste non è la stessa cosa di una policy corretta.
Cosa deve coprire una checklist di sicurezza per Lovable?
| Controllo | Perché conta | Come verificarlo |
|---|---|---|
| RLS attiva su ogni tabella di uno schema esposto | Senza di essa, Supabase permette a qualsiasi ruolo con un grant di leggere e scrivere l'intera tabella | Esegua il Security Advisor di Supabase; la regola 0013 (rls_disabled_in_public) lo segnala |
| Le policy corrispondono alle Sue regole | Una policy come USING (true) supera una scansione e lascia comunque passare tutti | Acceda come utente A, richieda le righe dell'utente B tramite l'API, e non deve ottenere nulla |
| Tabelle con RLS ma senza policy | Negano tutto, e il risultato appare come una funzionalità rotta, non come una fuga di dati | Regola 0008 dell'advisor (rls_enabled_no_policy); poi scriva la policy di cui la funzionalità ha bisogno |
| Nessuna chiave segreta nel browser | La chiave service role scavalca ogni policy RLS | Cerchi nel JavaScript compilato sb_secret_ o una chiave service_role legacy; ruoti qualsiasi chiave sia mai stata distribuita |
| Controlli lato server su tutto ciò che costa denaro | Il codice client può essere modificato da chi lo usa | Chiami direttamente la Sua edge function con un prezzo o un piano modificato e si aspetti un rifiuto |
| Limitazione delle richieste su registrazione, accesso e chiamate all'IA | Richieste illimitate si trasformano in abusi o in una bolletta a sorpresa | In staging, lanci con uno script 100 richieste rapide e verifichi che la maggior parte venga rifiutata |
| Protezione dalle password compromesse e MFA per gli amministratori | Le password riutilizzate da altre violazioni sono una via d'ingresso comune | Provi una password nota come compromessa in fase di registrazione |
| Un registro di audit e il monitoraggio degli errori | Non si può indagare su ciò che non è stato registrato | Faccia una modifica amministrativa in staging e la ritrovi nel registro |
Come correggo gli errori RLS di Supabase in un'app Lovable?
Gli errori RLS sono di due tipi opposti, ed è utile sapere quale dei due ha.
- Permesso negato (errore Postgres 42501, o un risultato vuoto). La RLS è attiva e nessuna policy consente la richiesta. È la RLS che funziona. Scriva la policy più ristretta che fa funzionare la funzionalità, per esempio le righe in cui la colonna del proprietario è uguale all'ID dell'utente autenticato.
- Tutto funziona per tutti. Il caso più pericoloso. Una policy come USING (true), o la RLS non attivata, lascia passare qualsiasi utente. L'advisor di Supabase segnala le policy permissive (regola 0024, permissive_rls_policy) e le policy che esistono mentre la RLS è disattivata (regola 0007, policy_exists_rls_disabled).
- Policy che leggono i metadati dell'utente. Supabase sconsiglia di basare le policy su metadati che l'utente può modificare da sé (regola 0015, rls_references_user_metadata). Usi invece una tabella controllata dal Suo server, come una tabella delle appartenenze ai team.
Quando chiede a Lovable di correggere una policy, ripeta poi il test con due utenti. Un prompt che fa sparire un errore può riuscirci allargando l'accesso, che è esattamente il guasto che cerca di evitare.
Quali chiavi si possono esporre in un'app Lovable?
La documentazione di Supabase dice che la chiave pubblicabile (anon) si può esporre, perché raggiunge solo ciò che la row-level security consente. Una chiave segreta, compresa la chiave service role, scavalca ogni policy RLS e non deve mai finire in un browser, in un'app distribuita o nel controllo di versione. La voce del glossario sulla chiave anon e la chiave service role spiega la differenza. I segreti di terzi, come le chiavi di Stripe o del fornitore email, vanno nei segreti delle edge function, non nel codice dell'app. Veda la gestione dei segreti.
Ogni quanto va ricontrollata un'app Lovable live?
Dopo ogni modifica che tocca dati, accessi o pagamenti, e periodicamente per tutto il resto: le dipendenze ricevono nuove vulnerabilità, le chiavi vanno ruotate e arrivano nuove tabelle con nuove policy. Per questo la sicurezza funziona meglio come abitudine che come audit. Nei nostri piani, controlli di sicurezza, revisione del codice e test di regressione vengono eseguiti su ogni modifica prima che arrivi in produzione, e uno sviluppatore diverso dall'autore la approva.
Domande frequenti
Lovable è sicuro per un'app aziendale reale?
Lovable è un buon luogo dove costruire e dare forma a un'app, e cerca gli errori di sicurezza comuni. Che l'app finita sia sicura dipende dalle sue regole di accesso, dalle sue chiavi e dal suo codice server, che dovrebbe verificare prima dell'arrivo di utenti e dati reali. La documentazione di Lovable dice che le sue scansioni non possono garantire una sicurezza completa.
La chiave anon di Supabase nella mia app Lovable è un problema di sicurezza?
No. Supabase documenta la chiave pubblicabile (anon) come esponibile, perché può raggiungere solo ciò che la row-level security consente. Diventa un problema solo quando la RLS è disattivata o troppo ampia. La chiave service role è diversa: scavalca la RLS e non deve mai trovarsi nel browser.
Il CVE-2025-48757 riguarda ancora le app Lovable?
Il CVE copre i siti generati da Lovable fino al 15 aprile 2025, e Lovable lo contesta. Da allora Lovable ha aggiunto una scansione di sicurezza. Qualsiasi app, vecchia o nuova, può comunque contenere una policy troppo ampia, quindi verifichi le Sue tabelle con due account utente invece di affidarsi alla data.
Quanto costa una revisione di sicurezza di un'app Lovable?
Molti freelance e aziende vendono revisioni una tantum a prezzo fisso. Con un piano Plutonapps, controlli di sicurezza e revisione del codice vengono eseguiti su ogni modifica come parte del prezzo mensile, insieme a sviluppo, test, rilascio e gestione dell'app. Piani e prezzi sono nella nostra pagina dei prezzi.
Posso eseguire da solo i controlli di sicurezza?
Sì. Lovable esegue la sua scansione rapida alla pubblicazione, il Security Advisor di Supabase è nella dashboard del Suo progetto, e il test con due utenti della checklist richiede solo due account di prova. Ciò che è più difficile fare da soli è continuare a farlo su ogni modifica, per tutto il tempo in cui l'app è live.
Dai nostri progetti
Termini in questa pagina
Confronti e guide correlati
- La Sua app Lovable non funziona in produzione? Come renderla pronta — Perché le app che funzionano in anteprima si rompono con utenti reali, i controlli che le rendono pronte per la produzione, e chi le mantiene in funzione.
- Come migrare da Lovable Cloud al Suo Supabase — Lovable Cloud o il Suo Supabase, cosa include e cosa esclude l'export, e un piano di passaggio che mantiene la produzione in funzione.
- Come assumere uno sviluppatore Lovable (e quanto costa) — Freelance, agenzie partner di Lovable e abbonamenti di sviluppo a confronto su costi, ambito e su chi gestisce l'app in seguito.
- Piani e prezzi
Fonti
Ogni dato esterno in questa pagina è stato verificato sulla fonte collegata il 30 September 2026. Prezzi e piani cambiano; segua i link per i valori aggiornati.