Be Bolt rätta rättigheterna för just den tabell som felar, inte öppna databasen. Prova sedan appen utloggad och med två inloggade testkonton, och öppna säkerhetssidan igen. Ett fel som försvinner visar bara att appen kommer åt tabellen. Det visar inte att rätt personer gör det.
Vad Bolt ändrade
Enligt Bolts release notes för veckan 26 oktober till 1 november håller Bolt database från den 30 oktober tabeller privata som standard. Appen behöver uttryckliga rättigheter för att läsa eller skriva i dem. Ändringen gäller nya tabeller skapade efter den 30 oktober, och befintliga databaser berörs inte. När Bolt skapar en ny databas bör rättigheterna enligt notisen sättas upp åt dig. Bolt skriver should, så se det som en förväntan, inte ett löfte. Får du ett behörighetsfel säger notisen att du kan be Bolt rätta tabellens rättigheter.
Notisen är kort och lämnar fyra saker öppna:
- Felets orsak. Bolt skriver att ett behörighetsfel could be related, alltså kan höra ihop med ändringen. Det står inte att alla sådana fel gör det. Gäller felet en tabell från före ändringen talar notisen emot sambandet, och då är det vår slutsats att du ska leta efter en annan orsak.
- Själva datumet. Notisen skriver både starting October 30 och created after October 30. Vad som gäller en tabell skapad just den dagen framgår inte.
- Ny tabell i en gammal databas. Nya tabeller omfattas och befintliga databaser berörs inte, men fallet där de möts tas inte upp uttryckligen. Se det inte som ett frikort. Prova tabellen.
- Andra databaser. Notisen nämner Bolt database. Om en databas som du själv hanterar i Supabase omfattas står inte där.
Rättigheter och policyer, utan kod
Bolts säkerhetsdokumentation beskriver en tabell som ett kalkylark: en tabell kan rymma alla order, med en order på varje rad. Row-level security, RLS, är den funktion i databasen som avgör vilka rader en förfrågan får läsa eller ändra. Policyer är reglerna som säger vem som når vilka rader, till exempel att en person bara ser de rader hen själv har skapat. Vill du förstå databasen i stort först finns artikeln om vilken databas du ska välja.
Två sidor måste läsas ihop, och Bolt förklarar inte sambandet på dem. Notisen talar om permissions och nämner inte RLS. Säkerhetssidan talar om RLS och policyer, är odaterad och nämner inte ändringen. Där står också att Bolt slår på RLS för tabeller som Bolt skapar, att du själv ska kontrollera tabeller du lägger till och att en tabell utan RLS kan läsas och ändras av vem som helst. Vår slutsats: ”privat som standard” är inget skäl att hoppa över kontrollen. Hur en policy skrivs lämnar vi åt Bolt och dess dokumentation.
Fallan: felet försvinner för att allt öppnades
Enligt säkerhetssidan kan Bolt, om du inte har bett om inloggning, skriva policyer som låter varje besökare visa, lägga till, ändra och ta bort data. Säkerhetssidan visar då varningen RLS Policy Always True: en policy saknar villkor som begränsar vem som når en rad. Bolt kallar den acceptabel bara om du kan leva med att varje besökare kan ändra eller ta bort datan.
Bolt kopplar inte det här till ändringen i oktober. Kopplingen är vår: den som har bråttom och skriver ”få det att fungera” beställer ett resultat, inte en gräns. Appen kan börja fungera precis lika bra om tabellen blev öppen för alla. Säg därför vad som ska gälla per tabell. Bolts dokumentation ger tre val, som du ser i tabellen nedan.
Färdiga önskemål till Bolt
De tre valen och exemplen på data kommer från Bolt, men formuleringarna är våra och har inte körts. Byt ut hakparenteserna mot dina egna namn.
| Läge | Passar för | Skriv till Bolt |
|---|---|---|
| Du får ett fel | En sida som inte kommer åt sin data | Jag får ett behörighetsfel på sidan [sida]. Ta reda på vilken tabell det gäller och rätta rättigheterna bara för den. Ge ingen mer åtkomst än appen behöver. Förklara på vanlig svenska vem som nu får läsa, lägga till, ändra och ta bort. |
| Besökare får bara läsa | Portfolio, meny, blogginlägg | Ändra rättigheterna för tabellen [inlägg] så att besökare kan läsa men inte lägga till, ändra eller ta bort. |
| Besökare får skicka in | Kontaktformulär, anmälningar, omdömen | Ändra rättigheterna för tabellen [meddelanden] så att besökare kan lägga till rader men inte läsa, ändra eller ta bort det som andra har skickat in. |
| Data ska vara privat | Kundorder, meddelanden | Lägg till inloggning med e-post. Ändra sedan rättigheterna för tabellen [order] så att inloggade bara kan visa, lägga till, ändra och ta bort sina egna rader. |
| Du vill kontrollera allt | När du är osäker på vad som är skyddat | Kontrollera att row-level security är på för alla tabeller i min databas och att varje policy bara ger den åtkomst min app behöver. |
Inloggningsraden finns av ett skäl. Enligt Bolt kan en policy begränsa data till bestämda personer först när appen vet vem varje besökare är. Utan inloggning finns inget ”sina egna” att begränsa till.
Provet: utloggad och två inloggade
Det här provet beskriver inte Bolt, det är vår metod, och vi har inte kört den i Bolt. Du behöver inte läsa kod. Gör det i den app dina besökare använder och med påhittade uppgifter. Samma tanke finns stegvis i guiden om behörigheter i Lovable, där verktyget är ett annat.
| Vem | Tabell som bara ska läsas | Formulär | Privata order |
|---|---|---|---|
| Utloggad | Ser alla inlägg, kan inte ändra | Kan skicka in, ser inte andras | Ser ingen order |
| Inloggad A | Samma | Samma | Ser Provorder A, inte B |
| Inloggad B | Samma | Samma | Ser Provorder B, inte A |
Facit ovan är ett påhittat exempel. Din app kan ha andra regler, och då ska facit se annorlunda ut. Felet kan också gå åt andra hållet: visar rutan att något ska fungera men appen ger ett behörighetsfel är rättigheten för snäv, och då är första önskemålet i listan rätt väg.
Vad provet inte visar
Provet ser bara appens skärmar. Enligt Bolt kan vem som helst som besöker en sida skicka förfrågningar direkt till databasen utan att gå via skärmarna. Att en rad inte syns på sidan bevisar alltså inte att databasen vägrar lämna ut den. Därför behövs också säkerhetssidan, som finns på alla planer:
Säkerhetssidan har sin egen gräns. Den kontrollerar bara databasen, inte hela projektet och dess kod. Vår tolkning är också att en tom lista inte kan säga att Provorder A är rätt persons rad, för det vet bara du. Därför behöver du både sidan och provet. Fler fallgropar i appar du inte har skrivit själv finns i guiden om säkerhet och personuppgifter.
Du har ett skrivet facit per tabell. Utloggad, A och B ser det facit säger, och den egna raden går att ändra. Säkerhetssidan är öppnad efter den senaste databasändringen, och varje kvarvarande RLS Policy Always True gäller data du kan låta alla besökare ändra eller ta bort. Testkonton och provrader är borttagna.
FAQ
Beror alla behörighetsfel i Bolt på ändringen?
Inte nödvändigtvis. Bolt skriver att ett behörighetsfel kan höra ihop med ändringen, inte att det alltid gör det. Ändringen gäller nya tabeller skapade efter den 30 oktober 2026.
Berörs mina befintliga databaser?
Enligt Bolt berörs inte befintliga databaser. Hur en ny tabell i en befintlig databas behandlas står inte uttryckligen i notisen, så prova den tabellen.
Hur ber jag Bolt rätta felet utan att öppna för alla?
Nämn sidan och tabellen, be Bolt rätta rättigheterna bara för den tabellen och säg vad besökare ska få göra. Öppna sedan säkerhetssidan igen och gör provet med utloggad och inloggad besökare.
Vad betyder varningen RLS Policy Always True?
En policy saknar villkor som begränsar vem som når en rad. Bolt skriver att varningen bara är acceptabel om du kan leva med att varje besökare kan ändra eller ta bort den datan.