Säkerhetschecklista för Lovable-appar: är din app säker?
Lovable, plattformen, och appen du byggt på den säkras var för sig. Lovable skannar efter vanliga misstag, men din app är bara så säker som sina egna åtkomstregler, nycklar och sin egen serverkod. Kontrollera att radnivåsäkerhet är påslagen för varje exponerad tabell och stämmer med vem som får se vad, att ingen hemlig nyckel når webbläsaren, att betalningar bekräftas på servern och att någon håller koll på appen i drift.
- Bakom CVE-2025-48757
- Radnivåsäkerhet avslagen, eller för bred
- Säker att skicka med
- Supabases publicerbara nyckel (anon)
- Skicka aldrig med
- Service role-nyckeln eller andra hemliga nycklar
- Kontrollera igen
- Efter varje ändring som rör data eller åtkomst
Är Lovable säkert, och gör det min app säker?
Lovable säger att de stöder kraven i SOC 2 och GDPR och publicerar sin säkerhetsdokumentation i sitt trust center. Det täcker Lovables plattform: dess infrastruktur, dess åtkomstkontroller, dess personal. Det täcker inte reglerna i din app, eftersom du (med Lovables hjälp) skrev dem.
Lovables säkerhetsskanning kör en snabb kontroll varje gång du publicerar: en databasgenomgång, en granskning av beroenden och en kontroll av MCP-servrar. En djupare skanning, som startas för hand (eller enligt schema, för Lovable Enterprise-kunder), granskar också åtkomstkontroll, oautentiserade endpoints, injektion, läckta hemligheter, betalningar, autentisering och exponerade personuppgifter. Lovables egen dokumentation är tydlig med att dessa verktyg inte kan garantera fullständig säkerhet. Se skanningen som en brandvarnare, inte en besiktning.
Vad var CVE-2025-48757, och påverkar den min app?
CVE-2025-48757, publicerad i maj 2025, beskriver otillräckliga policyer för radnivåsäkerhet i webbplatser genererade av Lovable fram till 15 april 2025, som lät oautentiserade angripare läsa eller skriva databastabeller. Den amerikanska National Vulnerability Database listar den med ett kritiskt CVSS 3.1-värde på 9,3 och noterar att Lovable bestrider den, med motiveringen att varje kund ansvarar för att skydda data i sin egen app.
Forskaren som rapporterade den, Matt Palmer, säger att han skannade 1 645 projekt och hittade 303 sårbara endpoints i 170 av dem, och att Lovable släppte sin säkerhetsskanning med Lovable 2.0 i april 2025. Vilken syn du än har på tvisten är den praktiska lärdomen densamma: om din app genererades före dess, eller om du har ändrat tabeller sedan dess, kontrollera dina policyer själv. En policy som finns är inte samma sak som en policy som är rätt.
Vad bör en säkerhetschecklista för Lovable täcka?
| Kontroll | Varför det spelar roll | Så testar du det |
|---|---|---|
| RLS påslaget på varje tabell i ett exponerat schema | Utan det låter Supabase varje roll med behörighet läsa och skriva hela tabellen | Kör Supabases Security Advisor; lint 0013 (rls_disabled_in_public) flaggar det |
| Policyerna stämmer med dina regler | En policy som USING (true) klarar en skanning och släpper ändå igenom alla | Logga in som användare A, begär användare B:s rader via API:et, förvänta dig att inget kommer tillbaka |
| Tabeller med RLS men utan policy | De nekar allt, vilket syns som en trasig funktion, inte en läcka | Advisor-lint 0008 (rls_enabled_no_policy); skriv sedan den policy funktionen behöver |
| Inga hemliga nycklar i webbläsaren | Service role-nyckeln kringgår varje RLS-policy | Sök i det byggda JavaScriptet efter sb_secret_ eller en äldre service_role-nyckel; rotera varje nyckel som någon gång skickats ut |
| Kontroller på servern för allt som kostar pengar | Klientkod kan ändras av den som använder den | Anropa din edge function direkt med ändrat pris eller ändrad plan och förvänta dig ett nej |
| Begränsning av anrop vid registrering, inloggning och AI-anrop | Obegränsade anrop leder till missbruk eller en oväntad faktura | Mot staging, skripta 100 snabba anrop och bekräfta att de flesta nekas |
| Skydd mot läckta lösenord och MFA för administratörer | Lösenord som återanvänts från andra intrång är en vanlig väg in | Prova ett känt läckt lösenord vid registrering |
| En granskningslogg och felövervakning | Du kan inte utreda det du inte registrerade | Gör en adminändring i staging och hitta den i loggen |
Hur åtgärdar jag RLS-fel i Supabase i en Lovable-app?
RLS-fel finns i två motsatta varianter, och det hjälper att veta vilken du har.
- Åtkomst nekad (Postgres-fel 42501, eller ett tomt resultat). RLS är påslaget och ingen policy tillåter begäran. Det är RLS som fungerar. Skriv den snävaste policy som låter funktionen fungera, till exempel rader där ägarkolumnen är lika med den inloggade användarens id.
- Allt fungerar för alla. Det farligare fallet. En policy som USING (true), eller en RLS-brytare som saknas, släpper igenom vilken användare som helst. Supabases rådgivare flaggar tillåtande policyer (lint 0024, permissive_rls_policy) och policyer som finns medan RLS är avslaget (lint 0007, policy_exists_rls_disabled).
- Policyer som läser användarmetadata. Supabase varnar för att basera policyer på metadata som en användare själv kan ändra (lint 0015, rls_references_user_metadata). Använd i stället en tabell som din server styr, till exempel en tabell över teammedlemskap.
När du ber Lovable åtgärda en policy, kör tvåanvändartestet igen efteråt. En prompt som får ett fel att försvinna kan göra det genom att vidga åtkomsten, vilket är precis det fel du försöker förhindra.
Vilka nycklar är säkra att exponera i en Lovable-app?
Supabases dokumentation säger att den publicerbara nyckeln (anon) är säker att exponera, eftersom den bara når det som radnivåsäkerheten tillåter. En hemlig nyckel, inklusive service role-nyckeln, kringgår varje RLS-policy och får aldrig hamna i en webbläsare, en utskickad app eller versionshanteringen. Ordlistans post om anon-nyckeln och service role-nyckeln förklarar skillnaden. Hemligheter från tredje part, som nycklar till Stripe eller e-postleverantören, hör hemma i edge functions hemligheter, inte i appens kod. Se hantering av hemligheter.
Hur ofta bör en Lovable-app i drift kontrolleras igen?
Efter varje ändring som rör data, åtkomst eller betalningar, och enligt ett schema för allt annat: beroenden får nya sårbarheter, nycklar bör roteras och nya tabeller kommer med nya policyer. Därför fungerar säkerhet bättre som en vana än som en granskning. På våra planer körs säkerhetskontroller, kodgranskning och regressionstester på varje ändring innan den når produktion, och en annan utvecklare än den som skrev koden godkänner den.
Vanliga frågor
Är Lovable säkert att använda för en riktig affärsapp?
Lovable är en rimlig plats att bygga och forma en app på, och det skannar efter vanliga säkerhetsmisstag. Om den färdiga appen är säker beror på dess egna åtkomstregler, nycklar och serverkod, som du bör verifiera innan riktiga användare och riktig data kommer. Lovables dokumentation säger att dess skanningar inte kan garantera fullständig säkerhet.
Är Supabases anon-nyckel i min Lovable-app ett säkerhetsproblem?
Nej. Supabase dokumenterar den publicerbara nyckeln (anon) som säker att exponera, eftersom den bara kan nå det som radnivåsäkerheten tillåter. Den blir ett problem bara när RLS är avslaget eller för brett. Service role-nyckeln är annorlunda: den kringgår RLS och får aldrig finnas i webbläsaren.
Påverkar CVE-2025-48757 fortfarande Lovable-appar?
CVE:n omfattar webbplatser genererade av Lovable fram till 15 april 2025, och Lovable bestrider den. Lovable har sedan dess lagt till en säkerhetsskanning. Vilken app som helst, gammal eller ny, kan fortfarande levereras med en policy som är för bred, så testa dina egna tabeller med två användarkonton i stället för att förlita dig på datumet.
Vad kostar en säkerhetsgranskning av en Lovable-app?
Engångsgranskningar säljs av många frilansare och byråer till fast pris. På en Plutonapps-plan körs säkerhetskontroller och kodgranskning på varje ändring som en del av månadspriset, tillsammans med att bygga, testa, leverera och drifta appen. Planer och priser finns på vår prissida.
Kan jag köra säkerhetskontrollerna själv?
Ja. Lovable kör sin snabba skanning när du publicerar, Supabases Security Advisor finns i din projektdashboard, och tvåanvändartestet i checklistan kräver bara två testkonton. Det som är svårare att göra ensam är att fortsätta göra det vid varje ändring, så länge appen är i drift.
Från vårt arbete
Begrepp på den här sidan
Relaterade jämförelser och guider
- Fungerar inte din Lovable-app i produktion? Så gör du den produktionsklar — Varför appar som fungerar i förhandsvisningen går sönder med riktiga användare, kontrollerna som gör en app produktionsklar och vem som håller den igång.
- Så flyttar du från Lovable Cloud till din egen Supabase — Lovable Cloud jämfört med egen Supabase, vad exporten tar med och lämnar kvar, och en plan för övergången som håller produktionen igång.
- Så anlitar du en Lovable-utvecklare (och vad det kostar) — Frilansare, Lovables partnerbyråer och utvecklingsabonnemang jämförda på kostnad, omfattning och vem som driftar appen efteråt.
- Planer och priser
Källor
Varje extern uppgift på den här sidan kontrollerades mot den länkade källan den 30 September 2026. Priser och planer ändras; följ länkarna för aktuella siffror.