Sikkerhedstjekliste for Lovable-apps: er din app sikker?
Lovable, platformen, og den app, du har bygget på den, sikres hver for sig. Lovable scanner efter almindelige fejl, men din app er kun så sikker som dens egne adgangsregler, nøgler og serverkode. Tjek, at row-level security er slået til for alle eksponerede tabeller og passer til, hvem der må se hvad, at ingen hemmelig nøgle når browseren, at betalinger bekræftes på serveren, og at nogen holder øje med appen i drift.
- Bag CVE-2025-48757
- Row-level security slået fra eller for bred
- Sikker at sende med
- Supabases publicerbare (anon) nøgle
- Send aldrig med
- Service role- eller andre hemmelige nøgler
- Tjek igen
- Efter hver ændring, der rører data eller adgang
Er Lovable sikkert, og gør det min app sikker?
Lovable siger, at de understøtter SOC 2- og GDPR-krav, og offentliggør deres sikkerhedsdokumentation i deres trust center. Det dækker Lovables platform: infrastrukturen, adgangskontrollen, medarbejderne. Det dækker ikke reglerne inde i din app, for dem skrev du (med Lovables hjælp).
Lovables sikkerhedsscanning kører et hurtigt tjek, hver gang du udgiver: en databasegennemgang, en gennemgang af afhængigheder og et tjek af MCP-servere. En grundigere scanning, som du starter manuelt (eller efter en tidsplan for Lovable Enterprise-kunder), gennemgår også adgangskontrol, endpoints uden autentificering, injection, lækkede hemmeligheder, betalinger, autentificering og eksponerede persondata. Lovables egen dokumentation er klar over, at de værktøjer ikke kan garantere fuld sikkerhed. Betragt scanningen som en røgalarm, ikke et eftersyn.
Hvad var CVE-2025-48757, og påvirker den min app?
CVE-2025-48757, offentliggjort i maj 2025, beskriver utilstrækkelige row-level security-politikker i Lovable-genererede sites frem til 15. april 2025, som lod angribere uden autentificering læse eller skrive i databasetabeller. Den amerikanske National Vulnerability Database angiver den med en kritisk CVSS 3.1-score på 9,3 og bemærker, at Lovable bestrider den med den begrundelse, at hver kunde selv er ansvarlig for at beskytte sin apps data.
Forskeren, der rapporterede den, Matt Palmer, siger, at han scannede 1.645 projekter og fandt 303 sårbare endpoints fordelt på 170 af dem, og at Lovable udgav sin sikkerhedsscanning med Lovable 2.0 i april 2025. Uanset hvad du mener om uenigheden, er den praktiske lære den samme: hvis din app blev genereret før da, eller hvis du har ændret tabeller siden, så tjek dine politikker selv. En politik, der findes, er ikke det samme som en politik, der er rigtig.
Hvad skal en sikkerhedstjekliste for Lovable dække?
| Tjek | Hvorfor det betyder noget | Sådan tester du det |
|---|---|---|
| RLS slået til på alle tabeller i et eksponeret skema | Uden det lader Supabase enhver rolle med en grant læse og skrive i hele tabellen | Kør Supabases Security Advisor; lint 0013 (rls_disabled_in_public) markerer det |
| Politikkerne passer til dine regler | En politik som USING (true) består en scanning og lukker stadig alle ind | Log ind som bruger A, bed om bruger B's rækker gennem API'et, og forvent intet tilbage |
| Tabeller med RLS, men uden politik | De afviser alt, hvilket viser sig som en funktion, der ikke virker, ikke som et læk | Advisor-lint 0008 (rls_enabled_no_policy); skriv derefter den politik, funktionen har brug for |
| Ingen hemmelige nøgler i browseren | Service role-nøglen omgår alle RLS-politikker | Søg i det byggede JavaScript efter sb_secret_ eller en ældre service_role-nøgle; rotér enhver nøgle, der nogensinde er sendt med |
| Tjek på serveren af alt, der koster penge | Klientkode kan redigeres af den person, der bruger den | Kald din edge function direkte med en ændret pris eller plan, og forvent en afvisning |
| Rate limiting på oprettelse, login og AI-kald | Ubegrænsede forespørgsler bliver til misbrug eller en overraskende regning | Mod staging: lav et script med 100 hurtige forespørgsler, og bekræft, at de fleste afvises |
| Beskyttelse mod lækkede adgangskoder og MFA for administratorer | Adgangskoder, der er genbrugt fra andre læk, er en almindelig vej ind | Prøv en kendt lækket adgangskode ved oprettelse |
| En revisionslog og fejlovervågning | Du kan ikke undersøge det, du ikke har registreret | Lav en administratorændring på staging, og find den i loggen |
Hvordan retter jeg Supabase RLS-fejl i en Lovable-app?
RLS-fejl findes i to modsatte slags, og det hjælper at vide, hvilken du har.
- Adgang nægtet (Postgres-fejl 42501, eller et tomt resultat). RLS er slået til, og ingen politik tillader forespørgslen. Det er RLS, der virker. Skriv den snævreste politik, der får funktionen til at virke, for eksempel rækker, hvor ejerkolonnen er lig med den indloggede brugers id.
- Alt virker for alle. Det farligste tilfælde. En politik som USING (true), eller en manglende RLS-kontakt, lukker enhver bruger ind. Supabases advisor markerer for brede politikker (lint 0024, permissive_rls_policy) og politikker, der findes, mens RLS er slået fra (lint 0007, policy_exists_rls_disabled).
- Politikker, der læser brugermetadata. Supabase advarer mod at basere politikker på metadata, som en bruger selv kan redigere (lint 0015, rls_references_user_metadata). Brug i stedet en tabel, som din server styrer, for eksempel en tabel over teammedlemskaber.
Når du beder Lovable om at rette en politik, så kør to-bruger-testen igen bagefter. En prompt, der får en fejl til at forsvinde, kan gøre det ved at udvide adgangen, hvilket netop er den fejl, du prøver at undgå.
Hvilke nøgler er sikre at eksponere i en Lovable-app?
Supabases dokumentation siger, at den publicerbare (anon) nøgle er sikker at eksponere, fordi den kun når det, som row-level security tillader. En hemmelig nøgle, inklusive service role-nøglen, omgår alle RLS-politikker og må aldrig komme i en browser, en udgivet app eller versionsstyring. Ordlisteopslaget om anon-nøglen og service role-nøglen forklarer forskellen. Tredjepartshemmeligheder, for eksempel nøgler til Stripe eller e-mailudbydere, hører hjemme i edge function-hemmeligheder, ikke i appens kode. Se håndtering af hemmeligheder.
Hvor tit bør en Lovable-app i drift tjekkes igen?
Efter hver ændring, der rører data, adgang eller betalinger, og efter en fast plan for alt andet: afhængigheder får nye sårbarheder, nøgler bør roteres, og nye tabeller kommer med nye politikker. Derfor virker sikkerhed bedre som en vane end som en revision. På vores planer kører sikkerhedstjek, kodegennemgang og regressionstests ved hver ændring, før den når produktion, og en anden udvikler end forfatteren godkender den.
Ofte stillede spørgsmål
Er Lovable sikkert at bruge til en rigtig forretningsapp?
Lovable er et fornuftigt sted at bygge og forme en app, og det scanner efter almindelige sikkerhedsfejl. Om den færdige app er sikker, afhænger af dens egne adgangsregler, nøgler og serverkode, som du bør verificere, før rigtige brugere og rigtige data kommer til. Lovables dokumentation siger, at deres scanninger ikke kan garantere fuld sikkerhed.
Er Supabase anon-nøglen i min Lovable-app et sikkerhedsproblem?
Nej. Supabase dokumenterer den publicerbare (anon) nøgle som sikker at eksponere, fordi den kun kan nå det, som row-level security tillader. Den bliver først et problem, når RLS er slået fra eller for bred. Service role-nøglen er anderledes: den omgår RLS og må aldrig ligge i browseren.
Påvirker CVE-2025-48757 stadig Lovable-apps?
CVE'en dækker Lovable-genererede sites frem til 15. april 2025, og Lovable bestrider den. Lovable har siden tilføjet en sikkerhedsscanning. Enhver app, gammel eller ny, kan stadig komme ud med en politik, der er for bred, så test dine egne tabeller med to brugerkonti i stedet for at stole på datoen.
Hvad koster en sikkerhedsgennemgang af en Lovable-app?
Engangsgennemgange sælges af mange freelancere og firmaer til fast pris. På en Plutonapps-plan kører sikkerhedstjek og kodegennemgang ved hver ændring som en del af månedsprisen, sammen med udvikling, test, lancering og drift af appen. Planer og priser står på vores prisside.
Kan jeg selv køre sikkerhedstjekkene?
Ja. Lovable kører sin hurtige scanning, når du udgiver, Supabases Security Advisor ligger i dit projekts dashboard, og to-bruger-testen i tjeklisten kræver kun to testkonti. Det, der er sværere at gøre alene, er at blive ved med det ved hver ændring, så længe appen er i drift.
Fra vores arbejde
Begreber på denne side
Relaterede sammenligninger og guides
- Virker din Lovable-app ikke i produktion? Sådan gør du den produktionsklar — Hvorfor apps, der virker i preview, går i stykker med rigtige brugere, de tjek, der gør en app produktionsklar, og hvem der holder den kørende.
- Sådan flytter du fra Lovable Cloud til din egen Supabase — Lovable Cloud eller din egen Supabase, hvad eksporten indeholder og udelader, og en plan for skiftet, der holder produktionen kørende.
- Sådan hyrer du en Lovable-udvikler (og hvad det koster) — Freelancere, Lovable-partnerbureauer og udviklingsabonnementer sammenlignet på pris, omfang og hvem der driver appen bagefter.
- Planer og priser
Kilder
Alle eksterne fakta på denne side blev tjekket mod den linkede kilde den 30 September 2026. Priser og planer ændrer sig; følg linkene for at se de aktuelle tal.