Supabase RLS: manuell granskning eller skanning?

Row Level Security är gränsen mellan ett Supabase-projekt som skyddar dess data och ett som tyst exponerar dem. När RLS är väl konfigurerad, upprätthåller din databas åtkomstregler på radnivå, för roller som omfattas av RLS. Privilegerade roller, inklusive tjänsterollen, kan kringgå dessa regler. När den är dåligt konfigurerad ser tabellerna skyddade ut medan policyerna släpper igenom mer än du tänkt dig.

Den här artikeln jämför två sätt att köra en Supabase RLS säkerhetskontroll: verifiera policyer för hand och köra en automatisk RLS granskning. Båda har en plats. Att veta var var och en går sönder är hur du verifierar att dina databasåtkomstpolicyer fungerar som avsett.

RLS är en Postgres-funktion som Supabase exponerar per bord. När den väl har aktiverats nekar en tabell radåtkomst till roller som omfattas av RLS om inte en policy tillåter det; tabellägare och roller med förbikopplingsbehörighet är undantag. Policyer utvärderas mot den aktuella användaren, deras anspråk och frågan som körs. Den auth.uid() funktion är vanligtvis ankaret: en policy som using (auth.uid() = user_id) begränsar åtkomsten till den inloggade användarens egna databasrader.

Modellen är ren. Misslyckanden är det inte, eftersom de sällan ser ut som misslyckanden.

Några mönster står för de flesta RLS-problem:

• RLS aktiverad på vissa bord, inte alla. En ny tabell som läggs till efter lansering, eller en som skapats genom en migrering, kan skickas med RLS avstängd. Varje rad är sedan läsbar av vilken roll som helst med tabellåtkomst.

• En policy som är bredare än den lyder. using (true) på en utvald policy betyder att varje rad är synlig. Det är lätt att lägga till under utveckling för felsökning och glömma att ta bort.

• Servicerollen antogs överallt. Kod på serversidan som använder tjänstrollnyckeln förbigår RLS helt. Om användarvänliga förfrågningar körs genom den nyckeln gäller aldrig policyerna.

• Policyer som kontrollerar fel kolumn. auth.uid() = id på ett bord där id är radens primärnyckel, inte ägaren, kommer aldrig att matcha avsikten. Policyn finns, den returnerar ett fel eller en tom uppsättning och ytan fungerar fortfarande.

• Databasuppdateringar och raderingar utan lämpliga åtkomstkontroller. Utvecklare säkerställer ofta valet noggrant och lämnar skrivpolicyer lösa. Att klara en läskontroll säger ingenting om vem som kan ändra raden härnäst.

Ingen av dessa meddelar sig själva. Var och en håller appen igång, vilket är exakt varför de överlever till produktion.

En manuell revision är direkt och kräver inga nya verktyg. Man arbetar igenom själva policyerna, tabell för tabell.

Börja med att lista varje tabell och bekräfta att RLS är aktiverat på var och en. Räkna sedan upp policyerna för varje tabell och mappa dem till avsedd åtkomst: vem som ska läsa, vem som ska skriva och vem som aldrig ska röra den. Läs varje policyuttryck mot kolumnen det jämför. Bekräfta att välj, infoga, uppdatera och ta bort var och en har en policy som matchar den avsedda rollen.

Kontrollera sedan kodsökvägen. Bestäm vilken nyckel som din applikation faktiskt använder för användarvänliga förfrågningar och om någon av dem kör igenom tjänstrollen. Skriv sedan testfrågor som olika användare och bekräfta att resultaten överensstämmer med förväntningarna: en användare ska läsa sina egna rader och ingen annans, och ska inte kunna uppdatera en rad de inte äger.

Manuell granskning är värt att göra, och det fångar mycket. Den har också förutsägbara döda fläckar.

• Den testar det du kommer ihåg att testa. Om du inte tänker försöka ta bort som en andra användare kan du missa en alltför bred raderingspolicy. Med RLS aktiverat betyder ingen tillämplig borttagningspolicy radering nekas.

• Den åldras. Policyerna glider när funktioner läggs till. En genomgång som var grundlig förra kvartalet säger ingenting om tabellen du lade till förra veckan.

• Det beror på samma person som konfigurerade policyerna. Byggaren som skrev policyn är minst benägen att upptäcka sitt eget antagande.

• Det behöver dokumenterade bevis. "Jag granskade det och det såg rätt ut" lämnar ingenting efter sig: inga bevis, inget omfattning, ingen artefakt som du kan skanna om senare.

Manuell revision svarar på frågan "stämmer detta överens med min mentala modell av systemet?" Det bevisar inte på egen hand vad databasen faktiskt kommer att returnera.

En automatisk Supabase RLS säkerhetskontroll fungerar från andra hållet. Den utövar projektet på det sätt som en angripare eller en felkonfigurerad klient skulle göra, och rapporterar vad datalagret faktiskt tillåter.

Det skiftet är viktigt av tre skäl. Först skalar den förbi minne: skanningen upprepar kontroller över de tabeller och slutpunkter som är tillgängliga inom dess konfigurerade omfattning. En extern skanning kan inte inspektera varje policy utan lämplig åtkomst. För det andra producerar det bevis som du kan agera på: upptäckten namnger tabellen, policytillståndet och villkoret som gjorde det tillgängligt, så att du vet vad du ska ändra och varför. För det tredje är det repeterbart. En kontroll som du kan köra igen förvandlar en engångsgranskning till pågående verifiering.

VICE skannar webbapplikationer och Supabase/RLS-konfigurationer och rapporterar sedan fynden med bevisen bakom dem och korrigeringsvägledning att arbeta utifrån. Du kan markera en korrigering och begära en ny kontroll, men bara en jämförbar omsökning bekräftar att problemet är löst: korrigeringen verifieras mot samma omfattning, inte antas från redigeringen. Schemalagda skanningar och varningar stödjer fortlöpande övervakning, så en tabell som läggs till nästa månad återinför inte i tysthet gapet.

Arbetsfördelningen är okomplicerad. Kör den automatiska kontrollen för att hitta vad din manuella granskning missade, använd sedan ett manuellt pass för att bekräfta avsikten bakom varje policy som skanningen flaggar. Automation berättar vad databasen tillåter; du bestämmer om tillståndet var avsiktligt.

En poäng från en skanning beskriver det testade omfattningen, inte en garanti för att ett projekt är helt säkert. Behandla det som en signal om var du ska leta, inte ett certifikat.

Om du distribuerar en produkt byggd med Supabase och aldrig har granskat dina policyer, är det ärliga svaret både och, i ordning. Börja med en automatiserad RLS-kontroll så att du har en aktuell, bevisad bild av vad dina tabeller tillåter. Gå sedan igenom resultaten för hand, bekräfta avsikten med varje policy och fixa de som drev. Lägg den automatiska kontrollen på ett schema så att nya tabeller och nya policyer får samma granskning som de ursprungliga.

Att hoppa över endera tillvägagångssättet kan lämna en databasåtkomstpolicy som verkar skydda data men fortfarande tillåter obehörig åtkomst.

Starta en gratis skanning på vice-platform.com för att kontrollera din offentliga webbplats innan du registrerar dig. En specialiserad Supabase-skanning kräver en verifierad domän och en betald prenumeration eller köpt kredit; dess täckning beror på den konfigurerade åtkomsten.