Skapa två testkonton med var sin påhittade privata post. Visa att konto B kan se sin egen post men varken läsa eller ändra A:s. Granska samtidigt reglerna på servern och skriv ned det faktiska utfallet.
Steg 1: skapa konton och ett tydligt facit
Välj en datatyp som ska vara privat, exempelvis anteckningar. Använd en testmiljö eller en tom testyta och skapa konto A och konto B med separata e-postadresser som du kontrollerar. Lägg in en syntetisk anteckning under varje konto: A-HEMLIG-TEST respektive B-HEMLIG-TEST. Använd inga riktiga kunduppgifter. Skriv ned appens adress, testmiljö, datum och vilken datatyp du provar.
Bestäm facit före provet. A ska få läsa och ändra sin post. B ska få läsa och ändra sin. B ska inte kunna läsa, ändra eller ta bort A:s post. Om appen avsiktligt delar poster inom ett team gäller ett annat facit; beskriv först vilka teammedlemmar som ska ha tillgång. Den här guiden gäller privat ägda poster.
Vet du inte var appens data lagras, börja med guiden om data och inloggning. Lovable-projekt kan ha olika backend. Be den som byggt appen visa var just den valda posten lagras.
Steg 2: granska reglerna bakom gränssnittet
Be byggaren visa tabellen eller lagringsytan, fältet som kopplar posten till en användare och serverns regler för läsning och ändring. I projekt med Lovables Cloud-databas visar Lovables säkerhetsdokumentation vägen More → Cloud → Database → RLS policies. Om projektet använder en annan backend ska du granska motsvarande regler där. En gömd knapp eller en filtrerad lista i webbläsaren är ingen serverkontroll.
Om appen använder Supabase/Postgres med RLS behöver du se både grants, som styr vilka operationer en databasroll får göra, och policyer, som styr vilka rader operationerna gäller. Supabases RLS-dokumentation skiljer uttryckligen mellan dessa två kontroller. Be om en enkel förklaring av varför A får läsa sin rad och varför B nekas samma rad.
Har posten ett ägarfält som user_id ska regeln jämföra det med identiteten från inloggningen, inte ett id som användaren själv skriver i formuläret. Supabases exempel använder auth.uid(). För ändring av en rad behöver byggaren även förklara vilka befintliga rader som får ändras och vilka nya värden som får sparas. Saknas en begriplig serverregel är appen inte redo för privata uppgifter.
Steg 3: prova egen och annans läsning
Logga in som A och leta upp A-HEMLIG-TEST i listan och detaljvyn. Facit är att A hittar sin post. Öppna sedan en separat privat webbläsarsession som B, så att kontonas sparade inloggningar inte blandas. B ska hitta B-HEMLIG-TEST men inte A:s markör i lista, sökning eller detaljvy.
Om A:s post har en direktlänk, kopiera den och öppna som B. Facit är ett nekat svar eller att posten inte hittas. Titta på innehållet, inte på exakt formulering av felmeddelandet. Om du kan använda webbläsarens nätverkspanel, kontrollera också att serverns vanliga svar inte innehåller A:s text. En rad som bara döljs visuellt kan redan ha skickats till B:s webbläsare.
Anteckna observationerna var för sig, till exempel: ”A såg sin post; B såg sin; A:s direktlänk gav 404 hos B; nätverkssvar inte granskat.” Skriv ”inte granskat” där du saknar underlag. Om B får A:s innehåll ska privata uppgifter inte användas förrän felet rättats och provats om.
Steg 4: prova att B inte kan ändra A:s post
Gör först ett positivt prov: låt B ändra sin egen anteckning till B-EGEN-ANDRAD och kontrollera efter omladdning att ändringen sparades. Öppna sedan A:s direkta redigeringsadress som B, om appen har en sådan. Om du behöver ange ett post-id i appens normala flöde, använd A:s syntetiska testpost. Be annars byggaren göra ett säkert negativt prov mot samma serverväg i testmiljön. Du behöver inte forcera en produktionsapp med verkliga poster.
Facit är att B:s försök nekas och att A:s post är oförändrad när A loggar in igen. Ett felmeddelande hos B räcker inte; kontrollera den sparade raden som A. Om B kan byta ägare, ändra texten eller ta bort A:s post är provet underkänt. Prova även andra operationer som appen erbjuder, till exempel borttagning, filbilagor eller export.
Supabase visar skilda regler för SELECT, INSERT, UPDATE och DELETE. Vid UPDATE skiljer dokumentationen mellan vilka rader som får väljas och vilka värden som får sparas. Be byggaren redovisa varje operation som appen använder. Om ett legitimt försök nekas kan det också bero på saknade grants. Ändra därför inte en RLS-policy på chans för att ett test misslyckades.
Steg 5: spara resultat och prova om
Gör en liten provmatris med konto, operation, post, förväntat utfall, faktiskt utfall och datum. Minst fyra rader behövs: A läser A, B läser B, B läser A och B ändrar A. De två första ska lyckas och de två sista nekas utan att A:s data ändras. Lägg gärna till omvända försök och ett prov som utloggad besökare om appens funktioner kan nås utan inloggning. Spara inte åtkomsttoken i rapporten.
Vid avvikelse, ge byggaren en avgränsad beställning: ”Som B kan jag öppna A:s anteckning via direktlänken. Begränsa läsning och ändring på servern till postens ägare, visa reglerna och kör om de fyra proven.” Kontrollera efter rättningen att A fortfarande kan använda sin egen post. Säkerhetsguiden hjälper dig med appens övriga risker.
Lovables Quick scan granskar bland annat databasregler och Deep scan kan granska åtkomstkontroll i kod. Kör relevanta skanningar i projektets Security view och gå igenom fynden. Leverantören säger själv att skanningarna inte garanterar full säkerhet. Två lyckade kontoprov visar bara beteendet för de konton, poster, operationer och vägar du faktiskt provat. Känsliga uppgifter eller kritiska funktioner kräver en bredare säkerhetsgranskning.
Du kan visa två testkonton, två syntetiska poster, granskade serverregler och en daterad provmatris där egen åtkomst fungerar och åtkomst till den andres post nekas.
Produktuppgifterna kontrollerades 1 oktober 2026 mot Lovables säkerhetsöversikt och Supabases RLS-dokumentation. Provrutinen är redaktionell och måste utföras på din egen app.