Varför RLS är viktigt för SaaS
Utan RLS är ditt API den enda barriären mellan en användare och varje rad i din databas. En oavsiktlig "hämta alla"-fråga och du har ett dataintrång.
Med RLS upprätthåller PostgreSQL åtkomstregler vid frågekörningstid. Oavsett vad ditt API skickar returnerar databasen bara rader som den autentiserade användaren får se. Detta är säkerhet-på-djupet — ditt API och din databas upprätthåller åtkomstkontroll oberoende av varandra.
Ur ett GDPR-perspektiv är detta guld: du kan visa för dina kunder (och deras DPO:er) att dataisolering upprätthålls på databasnivå — den starkaste möjliga tekniska garantin. Vid ett eventuellt dataskyddstillsynsärende är detta ett starkt bevis på privacy-by-design.
Aktivera RLS
Aktivera RLS på varje användarvändig tabell. Tabeller utan RLS-policyer är vidöppna som standard (om de nås via service-rollnyckeln) eller helt otillgängliga (om de nås via anon-nyckeln utan policyer).
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;
När det är aktiverat returneras inga rader som standard tills du skapar policyer. Detta är den korrekta säkerhetspositionen.
Skapa en checklista för ditt team: varje ny tabell får RLS aktiverat innan den ansluts till frontenden. Vi rekommenderar att lägga till detta som ett steg i er PR-mall eller deploy-checklista.
Den grundläggande användarägarskaps-policyn
Det vanligaste mönstret — användare kan bara se och ändra sina egna rader: CREATE POLICY "Users can view own rows" ON projects FOR SELECT USING (auth.uid() = user_id);
CREATE POLICY "Users can insert own rows" ON projects FOR INSERT WITH CHECK (auth.uid() = user_id);
CREATE POLICY "Users can update own rows" ON projects FOR UPDATE USING (auth.uid() = user_id);
CREATE POLICY "Users can delete own rows" ON projects FOR DELETE USING (auth.uid() = user_id);
Dessa fyra policyer täcker 80 % av alla enskilda användarappar. För B2C-appar — konsument-SaaS, personliga verktyg, individuella dashboards — är detta din fullständiga RLS-implementering.
Multi-tenant workspace-policyer
För SaaS med team och arbetsplatser kontrollerar du workspace-medlemskap: CREATE POLICY "Workspace members can view projects" ON projects FOR SELECT USING ( workspace_id IN ( SELECT workspace_id FROM workspace_members WHERE user_id = auth.uid() ) );
Detta kontrollerar workspace_members-kopplingstabell vid varje fråga. Indexera workspace_members(user_id, workspace_id) för prestanda.
För svenska B2B SaaS-bolag med enterprise-kunder: lägg till en organisationshierarki (t.ex. koncern → dotterbolag → avdelning) som ytterligare RLS-dimension. Det möjliggör koncernrapportering med korrekt dataisolering per enhet.
Rollbaserad åtkomstkontroll
Lägg till rollkontroll för adminoperationer: CREATE POLICY "Only admins can delete workspace projects" ON projects FOR DELETE USING ( workspace_id IN ( SELECT workspace_id FROM workspace_members WHERE user_id = auth.uid() AND role = 'admin' ) );
Lagra roller i din workspace_members-tabell (role text DEFAULT 'member'). Roller: owner, admin, member, viewer.
För mer granulär kontroll kan du bygga ett behörighetssystem (permissions-tabell) och kontrollera specifika åtgärder istället för roller. Men börja enkelt: owner/admin/member täcker 90 % av B2B SaaS-behoven.
Vanliga misstag att undvika
1. Glömma att aktivera RLS på nya tabeller. Skapa en checklista: varje ny tabell får RLS aktiverat innan den ansluts till frontenden.
2. Använda service-rollnyckeln i frontenden. Service-rollnyckeln kringgår RLS. Exponera den aldrig för användare — använd anon-nyckeln i WeWeb/FlutterFlow och service-rollen endast i serversidiga Xano-funktioner.
3. Ingen policy för INSERT. Många utvecklare lägger till SELECT- och UPDATE-policyer men glömmer INSERT. Utan det kan anon-nyckelsanvändare inte skapa rader alls.
4. N+1-policysökningar. Om din policy JOINar en stor tabell vid varje fråga ser du prestandaproblem i skala. Materialisera medlemskapssökningar eller använd index aggressivt. Testa alltid dina RLS-policyers prestanda med representativ datavolym innan du lanserar.