Supabase RLS: manuell kontroll eller skanning?

Row Level Security er grensen mellom et Supabase-prosjekt som beskytter dataene sine og et som stille eksponerer dem. Når RLS er godt konfigurert, håndhever databasen tilgangsregler på radnivå, for roller underlagt RLS. Privilegerte roller, inkludert tjenesterollen, kan omgå disse reglene. Når den er dårlig konfigurert, ser tabellene beskyttet ut mens policyene slipper gjennom mer enn du hadde tenkt.

Denne artikkelen sammenligner to måter å kjøre en Supabase RLS-sikkerhetssjekk på: å verifisere retningslinjer for hånd og å kjøre en automatisk RLS-revisjon. Begge har en plass. Å vite hvor hver enkelt bryter ned, er hvordan du bekrefter at retningslinjene for databasetilgang fungerer etter hensikten.

RLS er en Postgres-funksjon som Supabase viser per bord. Når den er aktivert, nekter en tabell radtilgang til roller underlagt RLS med mindre en policy tillater det; tabelleiere og roller med bypass-rettigheter er unntak. Retningslinjer blir evaluert mot gjeldende bruker, deres krav og spørringen som kjøres. Den auth.uid() funksjon er vanligvis ankeret: en politikk som using (auth.uid() = user_id) begrenser tilgangen til den påloggede brukerens egne databaserader.

Modellen er ren. Det er ikke feilene, for de ser sjelden ut som feil.

Noen få mønstre står for de fleste RLS-problemer:

• RLS aktivert på noen bord, ikke alle. En ny tabell lagt til etter lansering, eller en som er opprettet gjennom en migrering, kan sendes med RLS av. Hver rad kan deretter leses av enhver rolle med tabelltilgang.

• En politikk som er bredere enn den lyder. using (true) på en valgt policy betyr at hver rad er synlig. Det er lett å legge til under utvikling for feilsøking og glemme å fjerne.

• Tjenesterollen påtok seg overalt. Kode på serversiden som bruker tjenesterollenøkkelen, omgår RLS helt. Hvis brukervendte forespørsler kjører gjennom den nøkkelen, gjelder aldri retningslinjene.

• Retningslinjer som sjekker feil kolonne. auth.uid() = id på et bord hvor id er radens primærnøkkel, ikke eieren, vil aldri matche intensjonen. Policyen eksisterer, den returnerer en feil eller et tomt sett, og overflaten fungerer fortsatt.

• Databaseoppdateringer og slettinger uten passende tilgangskontroller. Utviklere sikrer ofte utvalg grundig og lar skriveretningslinjer stå løst. Å bestå en lesesjekk sier ingenting om hvem som kan endre raden neste.

Ingen av disse kunngjør seg selv. Hver og en holder appen i gang, og det er nettopp grunnen til at de overlever til produksjon.

En manuell revisjon er direkte og krever ingen nye verktøy. Du arbeider gjennom selve policyene, tabell for tabell.

Start med å liste opp hvert bord og bekreft at RLS er aktivert på hver enkelt. Deretter, for hver tabell, oppregne retningslinjene og kartlegge dem til tiltenkt tilgang: hvem skal lese, hvem skal skrive, og hvem skal aldri røre den. Les hvert policyuttrykk mot kolonnen det sammenligner. Bekreft at velg, sett inn, oppdater og slett hver har en policy som samsvarer med den tiltenkte rollen.

Deretter sjekker du kodebanen. Bestem hvilken nøkkel applikasjonen din faktisk bruker for brukervendte forespørsler, og om noen av dem kjører gjennom tjenesterollen. Skriv deretter testspørringer som forskjellige brukere og bekreft at resultatene samsvarer med forventningene: en bruker skal lese sine egne rader og ingen andres, og skal ikke kunne oppdatere en rad de ikke eier.

Manuell gjennomgang er verdt å gjøre, og det fenger mye. Den har også forutsigbare blindsoner.

• Den tester det du husker å teste. Hvis du ikke tenker på å prøve å slette som en annen bruker, kan du gå glipp av en altfor bred slettingspolicy. Med RLS aktivert betyr ingen gjeldende slettingspolicy sletting nektes.

• Den eldes. Retningslinjer avviker når funksjoner legges til. En gjennomgang som var grundig siste kvartal sier ingenting om tabellen du la til forrige uke.

• Det avhenger av den samme personen som konfigurerte policyene. Byggherren som skrev policyen er minst sannsynlig å oppdage sin egen antagelse.

• Det trenger dokumenterte bevis. "Jeg vurderte det og det så riktig ut" etterlater ingenting: ingen bevis, ingen omfang, ingen artefakter du kan skanne på nytt senere.

Manuell revisjon svarer på spørsmålet "matcher dette min mentale modell av systemet?" Det beviser ikke i seg selv hva databasen faktisk vil returnere.

En automatisert Supabase RLS sikkerhetssjekk fungerer fra den andre retningen. Den trener prosjektet slik en angriper eller en feilkonfigurert klient ville gjort, og rapporterer hva datalaget faktisk tillater.

Det skiftet er viktig av tre grunner. Først skalerer den forbi minnet: skanningen gjentar kontroller på tvers av tabellene og endepunktene som er tilgjengelige innenfor det konfigurerte omfanget. En ekstern skanning kan ikke inspisere alle policyer uten passende tilgang. For det andre produserer den bevis du kan handle på: funnene navngir tabellen, policytilstanden og tilstanden som gjorde det tilgjengelig, slik at du vet hva du skal endre og hvorfor. For det tredje er det repeterbart. En sjekk du kan kjøre på nytt gjør en engangsgjennomgang til løpende verifisering.

VICE skanner nettapplikasjoner og Supabase/RLS-konfigurasjoner, og rapporterer deretter funn med bevisene bak dem og rettingsveiledning å jobbe ut fra. Du kan merke en rettelse og be om en ny sjekk, men bare en sammenlignbar ny skanning bekrefter at problemet er løst: rettelsen er verifisert mot samme omfang, ikke antatt fra redigeringen. Planlagte skanninger og varsler støtter løpende overvåking, så en tabell som legges til neste måned, gjeninnfører ikke gapet stille.

Arbeidsfordelingen er grei. Kjør den automatiske sjekken for å finne hva den manuelle gjennomgangen din gikk glipp av, og bruk deretter et manuelt pass for å bekrefte intensjonen bak hver policy skanningen flagger. Automatisering forteller deg hva databasen tillater; du bestemmer om tillatelsen var bevisst.

En poengsum fra en hvilken som helst skanning beskriver det testede omfanget, ikke en garanti for at et prosjekt er helt sikkert. Behandle det som et signal om hvor du skal se, ikke et sertifikat.

Hvis du distribuerer et produkt bygget med Supabase og aldri har revidert retningslinjene dine, er det ærlige svaret begge deler, i orden. Start med en automatisert RLS-sjekk slik at du har et oppdatert, bevisstøttet bilde av hva tabellene dine tillater. Gå deretter gjennom funnene for hånd, bekrefte intensjonen med hver policy, og fiks de som drev. Sett den automatiserte sjekken på en tidsplan slik at nye tabeller og nye retningslinjer får samme gransking som de opprinnelige.

Å hoppe over begge tilnærmingene kan etterlate en databasetilgangspolicy som ser ut til å beskytte data, men som fortsatt tillater uautorisert tilgang.

Start en gratis skanning på vice-platform.com for å sjekke det offentlige nettstedet ditt før du registrerer deg. En spesialisert Supabase-skanning krever et verifisert domene og et betalt abonnement eller kjøpt kreditt; dens dekning avhenger av den konfigurerte tilgangen.