Supabase RLS: manuel kontrol eller scanning?

Row Level Security er grænsen mellem et Supabase-projekt, der beskytter sine data, og et, der stille og roligt afslører dem. Når RLS er konfigureret godt, håndhæver din database adgangsregler på rækkeniveau for roller underlagt RLS. Privilegerede roller, herunder servicerollen, kan omgå disse regler. Når det er dårligt konfigureret, ser tabellerne beskyttede ud, mens politikkerne slipper mere igennem, end du havde tænkt dig.

Denne artikel sammenligner to måder at køre et Supabase RLS sikkerhedstjek på: kontrol af politikker manuelt og kørsel af en automatisk RLS revision. Begge har en plads. At vide, hvor hver enkelt bryder sammen, er, hvordan du verificerer, at dine databaseadgangspolitikker fungerer efter hensigten.

RLS er en Postgres-funktion, som Supabase viser pr. bord. Når først den er aktiveret, nægter en tabel rækkeadgang til roller underlagt RLS, medmindre en politik tillader det; tabelejere og roller med bypass-rettigheder er undtagelser. Politikker evalueres i forhold til den aktuelle bruger, deres krav og den forespørgsel, der køres. Den auth.uid() funktion er normalt ankeret: en politik som using (auth.uid() = user_id) begrænser adgangen til den loggede brugers egne databaserækker.

Modellen er ren. Det er fejlene ikke, for de ligner sjældent fiaskoer.

Et par mønstre tegner sig for de fleste RLS-problemer:

• RLS aktiveret på nogle borde, ikke alle. En ny tabel tilføjet efter lancering, eller en oprettet gennem en migrering, kan sendes med RLS slukket. Hver række kan derefter læses af enhver rolle med tabeladgang.

• En politik, der er bredere, end den lyder. using (true) på en udvalgt politik betyder, at hver række er synlige. Det er nemt at tilføje under udvikling til fejlfinding og glemme at fjerne.

• Servicerollen påtaget sig overalt. Kode på serversiden, der bruger servicerollenøglen, omgår RLS fuldstændigt. Hvis brugervendte anmodninger kører gennem denne nøgle, gælder politikkerne aldrig.

• Politikker, der kontrollerer den forkerte kolonne. auth.uid() = id på et bord hvor id er rækkens primære nøgle, ikke ejeren, vil aldrig matche hensigten. Politikken eksisterer, den returnerer en fejl eller et tomt sæt, og overfladen opfører sig stadig.

• Databaseopdateringer og sletninger uden passende adgangskontrol. Udviklere sikrer ofte udvalg grundigt og lader skrivepolitikker stå løst. At bestå et læsetjek siger intet om, hvem der kan ændre rækken næste gang.

Ingen af disse meddeler sig selv. Hver enkelt holder appen i gang, hvilket er præcis grunden til, at de overlever til produktion.

En manuel revision er direkte og kræver ingen nye værktøjer. Du gennemarbejder selve politikkerne, tabel for tabel.

Start med at liste hver tabel og bekræft, at RLS er aktiveret på hver enkelt. Derefter, for hver tabel, opregn politikkerne og kortlæg dem til tilsigtet adgang: hvem skal læse, hvem skal skrive, og hvem må aldrig røre ved det. Læs hvert politikudtryk mod den kolonne, det sammenligner. Bekræft, at vælg, indsæt, opdater og slet hver har en politik, der matcher den tilsigtede rolle.

Derefter skal du kontrollere kodestien. Bestem, hvilken nøgle din applikation faktisk bruger til brugervendte anmodninger, og om nogen af ​​dem kører gennem tjenesterollen. Skriv derefter testforespørgsler som forskellige brugere og bekræft, at resultaterne svarer til forventningerne: en bruger skal læse deres egne rækker og ingen andres, og bør ikke kunne opdatere en række, de ikke ejer.

Manuel gennemgang er værd at gøre, og det fanger meget. Det har også forudsigelige blinde vinkler.

• Den tester, hvad du husker at teste. Hvis du ikke tænker på at prøve en sletning som en anden bruger, kan du gå glip af en alt for bred slettepolitik. Med RLS aktiveret betyder ingen gældende slettepolitik sletning afvises.

• Den ældes. Politikker glider, efterhånden som funktioner tilføjes. En gennemgang, der var grundig i sidste kvartal, siger intet om den tabel, du tilføjede i sidste uge.

• Det afhænger af den samme person, som har konfigureret politikkerne. Bygherren, der skrev politikken, er mindst tilbøjelig til at få øje på deres egen antagelse.

• Det kræver registrerede beviser. "Jeg har gennemgået det, og det så rigtigt ud" efterlader intet: ingen beviser, intet omfang, ingen artefakt, du kan genscanne senere.

Manuel auditering besvarer spørgsmålet "matcher dette min mentale model af systemet?" Det beviser ikke i sig selv, hvad databasen rent faktisk vil returnere.

Et automatiseret Supabase RLS sikkerhedstjek fungerer fra den anden retning. Den udøver projektet på samme måde som en angriber eller en forkert konfigureret klient, og rapporterer, hvad datalaget faktisk tillader.

Det skift er vigtigt af tre grunde. Først skalerer den forbi hukommelsen: scanningen gentager kontroller på tværs af tabeller og endepunkter, der er tilgængelige inden for dets konfigurerede omfang. En ekstern scanning kan ikke inspicere enhver politik uden passende adgang. For det andet producerer det beviser, du kan handle på: resultaterne navngiver tabellen, politiktilstanden og den tilstand, der gjorde det tilgængeligt, så du ved, hvad du skal ændre og hvorfor. For det tredje kan det gentages. En kontrol, du kan køre igen, forvandler en engangsgennemgang til løbende verifikation.

VICE scanner webapplikationer og Supabase/RLS-konfigurationer og rapporterer derefter resultater med beviserne bag dem og korrektionsvejledning, der kan arbejdes ud fra. Du kan markere en rettelse og anmode om en genkontrol, men kun en sammenlignelig genscanning bekræfter, at problemet er løst: rettelsen bekræftes i forhold til samme omfang, ikke antaget fra redigeringen. Planlagte scanninger og advarsler understøtter løbende overvågning, så en tabel tilføjet næste måned genindfører ikke stille og roligt hullet.

Arbejdsdelingen er ligetil. Kør det automatiserede tjek for at finde ud af, hvad din manuelle gennemgang gik glip af, og brug derefter et manuelt pas til at bekræfte hensigten bag hver politik, som scanningen markerer. Automatisering fortæller dig, hvad databasen tillader; du bestemmer, om tilladelsen var bevidst.

En score fra enhver scanning beskriver det testede omfang, ikke en garanti for, at et projekt er fuldt sikkert. Behandl det som et signal om, hvor du skal kigge, ikke et certifikat.

Hvis du implementerer et produkt bygget med Supabase og aldrig har revideret dine politikker, er det ærlige svar begge dele i orden. Start med et automatiseret RLS-tjek, så du har et aktuelt, evidensunderbygget billede af, hvad dine borde tillader. Gå derefter resultaterne i hånden, bekræft hensigten med hver politik, og ret dem, der svævede. Sæt det automatiske tjek på en tidsplan, så nye tabeller og nye politikker får samme kontrol som de oprindelige.

Hvis du springer over begge tilgange, kan det efterlade en databaseadgangspolitik, der ser ud til at beskytte data, men stadig tillader uautoriseret adgang.

Start en gratis scanning på vice-platform.com for at tjekke dit offentlige websted, før du tilmelder dig. En specialiseret Supabase-scanning kræver et verificeret domæne og et betalt abonnement eller købt kredit; dens dækning afhænger af den konfigurerede adgang.