És segur Lovable per a una app amb clients reals? El que protegeix sol i el que et toca a tu

La resposta curta

Lovable no és insegur per si mateix. Les apps que crea tenen tres parts: la web que veu l’usuari (s’executa al seu navegador i qualsevol en pot llegir el codi), unes funcions que s’executen al servidor (Edge Functions) i una base de dades PostgreSQL basada en Supabase. La mateixa documentació de Lovable ho resumeix així: el que és al navegador és públic i mai no s’ha de donar per fiable; qui decideix quines dades pot veure cada persona és la base de dades, amb les seves regles d’accés.

El problema apareix quan aquestes regles falten o estan mal escrites. Aleshores l’app funciona perfectament a la pantalla, però algú amb coneixements bàsics pot demanar a la base de dades, directament, les dades de tots els teus usuaris. Lovable ho deixa clar a la seva pàgina de seguretat: tu ets responsable que la teva app compleixi els requisits de seguretat que li corresponen, sobretot si gestiona dades sensibles.

Què fa Lovable per tu

Al setembre de 2026, això és el que Lovable revisa o protegeix sense que ho hagis de demanar, o amb un clic:

• Una revisió ràpida (Quick scan) cada vegada que obres el diàleg de publicar. Mira les regles d’accés de la base de dades (taules sense control per fila, regles que deixen passar tothom), la protecció de les contrasenyes i les llibreries amb errors coneguts.
• Una revisió a fons (Deep scan) que llances des de la vista Security del projecte. Busca al codi errors de permisos, funcions que es poden cridar sense iniciar sessió, injecció de dades, claus escrites al codi, trucs per manipular pagaments i dades personals que s’escolen en errors o registres. Les dues revisions són gratuïtes.
• Correccions automàtiques d’alguns problemes crítics recents de base de dades i de llibreries, que s’activen per espai de treball o per projecte. Corregir des de la vista Security amb Try to fix all fa servir un límit de 10 correccions gratuïtes, compartit amb la correcció d’errors de compilació; cadascuna torna a estar disponible 24 hores després de fer-la servir.
• Un ajust per impedir publicar mentre hi hagi problemes crítics sense resoldre. Sense aquest ajust, pots publicar igualment, tot i que Lovable ho desaconsella.
• Gestió de claus (Secrets). Si enganxes una clau d’API al xat, Lovable la reconeix i et proposa desar-la com a secret: es desa xifrada, només arriba a les funcions del servidor i mai al navegador. Un cop desada no es pot tornar a veure, només substituir o esborrar.
• Un ajust per rebutjar contrasenyes que ja apareixen en filtracions conegudes (la comprovació HIBP).

Per què no n’hi ha prou amb l’escàner

El març de 2025, l’investigador Matt Palmer va analitzar 1.645 apps fetes amb Lovable i va trobar 170 projectes (al voltant del 10 %) amb 303 punts d’accés a dades mal protegits: correus, noms, telèfons, claus d’API d’altres serveis i dades de pagaments i subscripcions. Només va mirar la pàgina d’inici de cada app, sense entrar en zones amb contrasenya. L’error es va publicar com a CVE-2025-48757 el maig de 2025, i la causa eren regles d’accés insuficients a la base de dades. L’octubre de 2025, l’empresa de seguretat Escape va revisar més de 5.600 apps fetes amb eines d’IA (unes 4.000 de Lovable) i va trobar més de 2.000 vulnerabilitats, més de 400 claus exposades i 175 casos de dades personals accessibles.

Des d’aleshores Lovable ha ampliat molt les seves revisions. Però un escàner no coneix les regles del teu negoci: sap si una taula té regles, no si un client de la teva clínica hauria de veure només les seves cites o també les de la seva família. Una regla pot existir i estar malament. Lovable ho reconeix: les seves revisions no substitueixen una revisió de seguretat completa.

Regles d’accés (RLS) a cada taula

La seguretat a nivell de fila (Row Level Security, RLS) és el que fa que cada usuari vegi només les seves dades. Supabase ho explica sense embuts: una taula exposada sense RLS la pot llegir i modificar qualsevol rol que hi tingui permís, i en molts projectes el rol dels visitants anònims el té d’entrada. Activar RLS sense escriure cap regla bloqueja l’accés; activar-la amb regles mal escrites dona una falsa sensació de seguretat.

Tres paranys habituals, segons la documentació de Supabase:

• Una regla del tipus "using (true)" per a visitants anònims deixa llegir totes les files a qualsevol. Només serveix per a dades que de debò són públiques, com un catàleg.
• Sense sessió iniciada, la funció que retorna l’usuari actual (auth.uid()) dona un valor buit. Una regla ben escrita ho comprova explícitament.
• Les vistes (views) creades amb l’usuari administrador se salten les regles de les taules que consulten. Una vista sobre una taula protegida pot lliurar justament les files que la taula amagava.

Les claus que viatgen al navegador

La teva app porta a dins una clau de Supabase, la publicable (abans anomenada anon). És normal i està pensada per ser pública: el seu poder depèn completament de les teves regles RLS. Si les regles estan bé, veure-la no serveix de res; si estan malament, n’hi ha prou amb aquesta clau per llegir les teves taules. L’anàlisi d’Escape va trobar claus d’aquest tipus al codi de moltes apps, juntament amb regles mal configurades: l’error no era la clau, eren les regles.

L’altra clau, la secreta (abans service_role), és una altra cosa: se salta totes les regles RLS. Supabase insisteix que mai no ha de ser en un navegador, en una app publicada ni al codi que puges a GitHub. El mateix val per a les claus de Stripe, d’OpenAI o de qualsevol servei que et cobri per ús: Lovable considera compromesa qualsevol clau que acabi al codi de la web. Al setembre de 2026, Supabase ha anunciat que retirarà les claus antigues (anon i service_role) a finals de 2026, així que si la teva app fa servir el seu propi projecte de Supabase convé passar ja a les noves.

Inici de sessió i rols

Lovable ho resumeix en una frase: totes les decisions d’accés s’han de prendre al servidor, no al navegador. Amagar el botó d’administració a qui no és administrador està bé per a la pantalla, però no protegeix res: qualsevol pot cridar la base de dades o les teves funcions sense passar per aquest botó.

Compte també amb on es desa el rol de cada usuari. Supabase adverteix que les metadades d’usuari (user_metadata) les pot modificar el mateix usuari, així que no serveixen per decidir qui és administrador. El rol ha de ser en un lloc que l’usuari no pugui canviar: les metadades de l’app (app_metadata) o una taula pròpia protegida amb RLS.

Pagaments i webhooks

Si cobres amb Stripe, la regla d’or és que la teva app no doni res per pagat perquè l’usuari arribi a la pàgina de gràcies. Stripe ho explica: no es pot confiar només en aquesta pàgina, perquè el client pot pagar i perdre la connexió abans de veure-la. El que és fiable és l’avís que Stripe envia al teu servidor (webhook) quan el pagament es confirma.

I aquest avís s’ha de comprovar: Stripe signa cada webhook i la teva funció n’ha de verificar la signatura amb el secret del punt de connexió (el que comença per whsec_) abans d’activar res. Si no, qualsevol podria enviar a aquesta adreça un fals "pagament completat".

Fitxers, límits d’ús i còpies de seguretat

Tres coses que no es veuen fins que fallen:

• Fitxers. A Supabase, un contenidor de fitxers (bucket) públic deixa descarregar qualsevol fitxer a qui tingui l’enllaç. Les factures, els DNI o les fotos de clients van en contenidors privats, amb regles que diguin qui pot pujar, veure o esborrar cada fitxer.
• Límits d’ús. Supabase limita per defecte l’inici de sessió: per exemple, 30 registres o accessos cada 5 minuts i 2 correus per hora amb el seu servidor de correu inclòs. Les teves pròpies funcions, com la que crida una IA de pagament o envia missatges, necessiten el seu propi límit perquè ningú no les cridi milers de vegades a costa teva; Supabase documenta com afegir-lo amb Upstash Redis.
• Còpies de seguretat. Amb Lovable Cloud pots restaurar còpies des de la secció Database. Si la teva app fa servir el teu propi Supabase, el pla gratuït no fa còpies automàtiques (Supabase recomana exportar les dades tu mateix) i el pla Pro desa les dels últims 7 dies.

La llista que pots seguir tu

Abans de convidar clients reals, o avui mateix si ja en tens:

1. Obre la vista Security del teu projecte, llança la revisió ràpida i la revisió a fons, i resol tot el que sigui crític.
2. Activa l’ajust que impedeix publicar amb problemes crítics.
3. Comprova que totes les taules amb dades d’usuaris tenen RLS activada i llegeix cada regla: busca les que deixen passar tothom.
4. Crea dos comptes de prova i intenta veure, amb el segon, les dades del primer. Si pots, alguna cosa no va bé.
5. Busca al codi de la web (i a GitHub, si el sincronitzes) qualsevol clau que no sigui la publicable de Supabase. Si n’apareix una, canvia-la al servei corresponent i desa-la com a secret.
6. Comprova on es desa el rol d’administrador i que la comprovació es fa a la base de dades o al servidor, no només a la pantalla.
7. Si cobres, confirma que el pagament es marca com a completat des del webhook i que la signatura es verifica.
8. Revisa quins contenidors de fitxers són públics i si res del que hi desen hauria de ser privat.
9. Posa un límit d’ús a les funcions que costen diners o envien missatges.
10. Esbrina com restauraries les teves dades demà si s’esborra alguna cosa, i prova de fer-ho una vegada.

Quan demanar una revisió

Si la teva app només desa correus d’una llista d’espera, la llista anterior i els escàners de Lovable et poden bastar. Demana que algú la revisi quan desis dades de salut, documents d’identitat o dades de menors; quan cobris dins de l’app; quan hi hagi diversos tipus d’usuari (clients, treballadors, administradors) que hagin de veure coses diferents; o quan no tinguis clar què fan les regles que Lovable ha escrit per tu. Una regla mal escrita no dona cap avís: l’app funciona igual.

Què faig jo a Omplia

Reviso apps fetes amb Lovable abans que tinguin clients, o quan ja en tenen: regles RLS taula per taula amb comptes de prova, claus, rols, pagaments, fitxers i còpies de seguretat. Et deixo per escrit què he trobat i què he canviat. Si la teva app ja està bé, t’ho diré.

Una app des de 2.900 € amb el preu de llançament, més un pla de manteniment mensual opcional, IVA no inclòs. El preu final depèn del que calgui fer i queda fixat per escrit abans de començar. La primera revisió del teu enllaç és gratis.