Sikkerhetssjekkliste for Lovable-apper: er appen din sikker?
Lovable, plattformen, og appen du har bygget på den, sikres hver for seg. Lovable skanner etter vanlige feil, men appen din er bare så trygg som sine egne tilgangsregler, nøkler og sin egen serverkode. Sjekk at radnivåsikkerhet er slått på for alle eksponerte tabeller og stemmer med hvem som kan se hva, at ingen hemmelig nøkkel når nettleseren, at betalinger bekreftes på serveren, og at noen følger med på appen i drift.
- Bak CVE-2025-48757
- Radnivåsikkerhet slått av, eller for vid
- Trygt å levere ut
- Supabases publiserbare (anon) nøkkel
- Lever aldri ut
- Service role-nøkler eller andre hemmelige nøkler
- Sjekk på nytt
- Etter hver endring som berører data eller tilgang
Er Lovable sikkert, og gjør det appen min sikker?
Lovable sier at de støtter kravene i SOC 2 og GDPR, og publiserer sikkerhetsdokumentasjonen sin i trust center-et sitt. Det dekker Lovables plattform: infrastrukturen, tilgangskontrollen og de ansatte. Det dekker ikke reglene inne i appen din, fordi det var du (med Lovables hjelp) som skrev dem.
Lovables sikkerhetsskanning kjører en rask sjekk hver gang du publiserer: en gjennomgang av databasen, en revisjon av avhengigheter og en sjekk av MCP-servere. En grundigere skanning, startet manuelt (eller etter en tidsplan, for Lovable Enterprise-kunder), går også gjennom tilgangskontroll, endepunkter uten autentisering, injeksjon, lekkede hemmeligheter, betalinger, autentisering og eksponerte personopplysninger. Lovables egen dokumentasjon er tydelig på at disse verktøyene ikke kan garantere full sikkerhet. Se på skanningen som en røykvarsler, ikke en inspeksjon.
Hva var CVE-2025-48757, og påvirker det appen min?
CVE-2025-48757, publisert i mai 2025, beskriver utilstrekkelige regler for radnivåsikkerhet i nettsteder generert av Lovable frem til 15. april 2025, som lot angripere uten autentisering lese eller skrive databasetabeller. Den amerikanske National Vulnerability Database oppfører den med en kritisk CVSS 3.1-score på 9,3 og påpeker at Lovable bestrider den, med den begrunnelse at hver kunde har ansvar for å beskytte dataene i sin egen app.
Forskeren som rapporterte den, Matt Palmer, sier at han skannet 1 645 prosjekter og fant 303 sårbare endepunkter i 170 av dem, og at Lovable lanserte sikkerhetsskanningen sin med Lovable 2.0 i april 2025. Uansett hva du mener om uenigheten, er den praktiske lærdommen den samme: hvis appen din ble generert før det, eller hvis du har endret tabeller siden, sjekk reglene dine selv. En regel som finnes, er ikke det samme som en regel som er riktig.
Hva bør en sikkerhetssjekkliste for Lovable dekke?
| Sjekk | Hvorfor det betyr noe | Slik tester du det |
|---|---|---|
| RLS slått på for alle tabeller i et eksponert skjema | Uten det lar Supabase enhver rolle med tilgang lese og skrive hele tabellen | Kjør Supabases Security Advisor; lint 0013 (rls_disabled_in_public) flagger det |
| Reglene stemmer med reglene dine | En regel som USING (true) består en skanning og slipper likevel alle gjennom | Logg inn som bruker A, be om radene til bruker B gjennom API-et, og forvent ingenting tilbake |
| Tabeller med RLS, men uten regel | De avviser alt, noe som viser seg som en ødelagt funksjon, ikke en lekkasje | Advisor-lint 0008 (rls_enabled_no_policy); skriv så regelen funksjonen trenger |
| Ingen hemmelige nøkler i nettleseren | Service role-nøkkelen omgår alle RLS-regler | Søk i det ferdigbygde JavaScriptet etter sb_secret_ eller en eldre service_role-nøkkel; roter alle nøkler som noen gang har vært levert ut |
| Sjekker på serveren for alt som koster penger | Klientkoden kan endres av personen som bruker den | Kall edge-funksjonen din direkte med endret pris eller plan, og forvent et avslag |
| Begrensning av forespørsler ved registrering, innlogging og KI-kall | Ubegrensede forespørsler blir til misbruk eller en overraskende regning | Mot staging: lag et skript med 100 raske forespørsler og bekreft at de fleste avvises |
| Beskyttelse mot lekkede passord og MFA for administratorer | Passord gjenbrukt fra andre datainnbrudd er en vanlig vei inn | Prøv et kjent lekket passord ved registrering |
| En revisjonslogg og feilovervåking | Du kan ikke undersøke det du ikke har registrert | Gjør en admin-endring i staging og finn den i loggen |
Hvordan fikser jeg RLS-feil fra Supabase i en Lovable-app?
RLS-feil kommer i to motsatte varianter, og det hjelper å vite hvilken du har.
- Ingen tilgang (Postgres-feil 42501, eller et tomt resultat). RLS er på, og ingen regel tillater forespørselen. Det er RLS som virker. Skriv den smaleste regelen som får funksjonen til å virke, for eksempel rader der eierkolonnen er lik ID-en til den innloggede brukeren.
- Alt virker for alle. Det farligste tilfellet. En regel som USING (true), eller en manglende RLS-bryter, slipper alle brukere gjennom. Supabases rådgiver flagger romslige regler (lint 0024, permissive_rls_policy) og regler som finnes mens RLS er av (lint 0007, policy_exists_rls_disabled).
- Regler som leser brukermetadata. Supabase advarer mot å basere regler på metadata en bruker kan endre selv (lint 0015, rls_references_user_metadata). Bruk heller en tabell serveren din kontrollerer, som en tabell over teammedlemskap.
Når du ber Lovable fikse en regel, kjør testen med to brukere på nytt etterpå. En prompt som får en feil til å forsvinne, kan gjøre det ved å utvide tilgangen, som er nøyaktig den feilen du prøver å unngå.
Hvilke nøkler er trygge å eksponere i en Lovable-app?
Supabases dokumentasjon sier at den publiserbare (anon) nøkkelen er trygg å eksponere, fordi den bare når det radnivåsikkerheten tillater. En hemmelig nøkkel, inkludert service role-nøkkelen, omgår alle RLS-regler og må aldri ligge i en nettleser, en levert app eller i kildekodekontroll. Ordlisteoppføringen om anon-nøkkelen og service role-nøkkelen forklarer forskjellen. Tredjepartshemmeligheter, som nøkler til Stripe eller e-postleverandøren, hører hjemme i hemmelighetene til edge-funksjonene, ikke i appens kode. Se håndtering av hemmeligheter.
Hvor ofte bør en Lovable-app i drift sjekkes på nytt?
Etter hver endring som berører data, tilgang eller betalinger, og etter en tidsplan for alt annet: avhengigheter får nye sårbarheter, nøkler bør roteres, og nye tabeller kommer med nye regler. Derfor fungerer sikkerhet bedre som en vane enn som en revisjon. På planene våre kjøres sikkerhetssjekker, kodegjennomgang og regresjonstester på hver endring før den når produksjon, og en annen utvikler enn den som skrev koden, godkjenner den.
Ofte stilte spørsmål
Er Lovable trygt å bruke for en ekte forretningsapp?
Lovable er et fornuftig sted å bygge og forme en app, og det skanner etter vanlige sikkerhetsfeil. Om den ferdige appen er trygg, avhenger av dens egne tilgangsregler, nøkler og serverkode, som du bør verifisere før ekte brukere og ekte data kommer. Lovables dokumentasjon sier at skanningene ikke kan garantere full sikkerhet.
Er Supabase-anon-nøkkelen i Lovable-appen min et sikkerhetsproblem?
Nei. Supabase dokumenterer at den publiserbare (anon) nøkkelen er trygg å eksponere, fordi den bare kan nå det radnivåsikkerheten tillater. Den blir et problem bare når RLS er av eller for vid. Service role-nøkkelen er noe annet: den omgår RLS og må aldri ligge i nettleseren.
Påvirker CVE-2025-48757 fortsatt Lovable-apper?
CVE-en dekker nettsteder generert av Lovable frem til 15. april 2025, og Lovable bestrider den. Lovable har siden lagt til en sikkerhetsskanning. Enhver app, gammel eller ny, kan fortsatt levere en regel som er for vid, så test dine egne tabeller med to brukerkontoer i stedet for å stole på datoen.
Hva koster en sikkerhetsgjennomgang av en Lovable-app?
Engangsgjennomganger selges av mange frilansere og firmaer til fast pris. På en Plutonapps-plan kjøres sikkerhetssjekker og kodegjennomgang på hver endring som en del av månedsprisen, sammen med bygging, testing, lansering og drift av appen. Planer og priser står på prissiden vår.
Kan jeg kjøre sikkerhetssjekkene selv?
Ja. Lovable kjører sin raske skanning når du publiserer, Supabases Security Advisor finnes i prosjektdashbordet ditt, og testen med to brukere i sjekklisten krever bare to testkontoer. Det som er vanskeligere å gjøre alene, er å fortsette med det på hver endring, så lenge appen er i drift.
Fra arbeidet vårt
Begreper på denne siden
Relaterte sammenligninger og guider
- Lovable-appen virker ikke i produksjon? Slik gjør du den klar — Hvorfor apper som virker i forhåndsvisningen, svikter med ekte brukere, sjekkene som gjør en app klar for produksjon, og hvem som holder den i drift.
- Slik flytter du fra Lovable Cloud til din egen Supabase — Lovable Cloud eller egen Supabase, hva eksporten tar med og etterlater, og en plan for overgangen som holder produksjon i gang.
- Slik leier du en Lovable-utvikler (og hva det koster) — Frilansere, Lovable-partnerbyråer og utviklingsabonnementer sammenlignet på pris, omfang og hvem som drifter appen etterpå.
- Planer og priser
Kilder
Alle eksterne fakta på denne siden ble kontrollert mot kilden det lenkes til, den 30 September 2026. Priser og planer endrer seg; følg lenkene for gjeldende tall.