Supabase i drift: Lad ikke en flot brugerflade være jeres adgangskontrol

Forstå den direkte vej fra browser til database

Supabase kan samle Postgres, Auth, Storage og et Data API. Det gør det muligt at lade en web- eller mobilapp læse data direkte med brugerens session. Det er en brugbar arkitektur, når adgangsreglerne håndhæves i databasen. Det er risikabelt, hvis appen kun skjuler menupunkter eller filtrerer data i frontend.

Åbn browserens udviklerværktøjer og find projektets Supabase-URL, den nøgle klienten bruger, og de kald der sendes til database, Auth og Storage. De oplysninger, som browseren allerede har, må betragtes som offentlige. En bruger kan kopiere et kald, ændre tabel, filter, id eller handling og sende det igen uden jeres skærmbillede.

Sortér nøglerne efter den adgang, de giver

Supabase skelner mellem en klientnøgle og en privilegeret servernøgle. Eksisterende projekter kan vise de ældre navne anon og service_role, mens nyere projekter bruger publishable og secret keys. Navnet er mindre vigtigt end den faktiske adgang.

En publishable nøgle må gerne være synlig i klienten, men den giver ikke i sig selv sikker adgang. En secret key omgår RLS og må aldrig ende i browserkode, en mobilapp, et offentligt repository eller en fejlbesked. Hvis den har været eksponeret, skal den behandles som lækket og roteres efter Supabases aktuelle procedure.

Lav en adgangsmatrix før I skriver RLS-politikker

Row Level Security er Postgres-regler, som afgør hvilke rækker en forespørgsel må læse eller ændre. Begynd med forretningen: Hvem må gøre hvad med hvilken organisations data? Skriv svaret ned for hver tabel og handling, før AI'en genererer SQL.

• Aktivér RLS på alle eksponerede tabeller og views: Gennemgå den faktiske database; stol ikke på, at et bestemt oprettelsesværktøj valgte en sikker standard.
• Begræns grants: Rollen skal kun kunne udføre de operationer, appen bruger. En RLS-politik og en tabelrettighed løser forskellige dele af adgangen.
• Skriv regler pr. handling: Læsning, oprettelse, ændring og sletning har sjældent samme betingelser.
• Bind data til bruger eller organisation: Kontrollér relationen i databasen; accepter ikke et virksomheds-id fra klienten som bevis.
• Afvis som standard: En ny tabel eller handling skal være lukket, indtil dens nødvendige adgang er beskrevet og testet.

Test afslag uden om appens skærmbilleder

Den vigtigste adgangstest er ofte den handling, som ikke må lykkes. Kør test med samme klienttype og session, som den rigtige app bruger. Ændr id'er og filtre, og kontrollér både svar og database efter forsøget.

1. Uden login: Kan en besøgende læse, oprette, ændre eller slette andet end bevidst offentlige data?
2. Bruger A mod bruger B: Kan den ene bruger gætte et id eller ændre et filter og få adgang til den andens post?
3. Virksomhed A mod virksomhed B: Beskyt alle veje gennem medlemskab, relationer og roller – ikke kun den mest synlige tabel.
4. Felter og ejerskab: Kan klienten ændre owner_id, organization_id, rolle, pris eller status til en værdi, som formularen normalt ikke tilbyder?
5. Sletning og massehandlinger: Kan ét kald påvirke flere rækker eller filer end brugeren forventer?

Supabase dokumenterer tests gennem klientkode eller Supabase CLI og pgTAP. Vælg den form, der passer til projektet, men gem både tilladte og afviste scenarier sammen med koden, så en senere AI-ændring ikke ubemærket åbner data.

Gennemgå også Storage, views og databasefunktioner

En sikker tabelpolitik er ikke nødvendigvis en sikker app. Filer og serverfunktioner har egne adgangsveje, og et view eller en databasefunktion kan returnere mere end den underliggende tabel gjorde gennem den forventede vej.

• Storage: Vælg offentlige buckets kun til filer, der reelt må være offentlige. Brug politikker pr. download, upload, ændring og sletning for private filer.
• Views: Kontrollér hvordan hvert eksponeret view forholder sig til RLS og databasebrugeren, der oprettede det.
• Databasefunktioner og RPC: Begræns hvem der må kalde dem. Gennemgå især funktioner, der kører med ejerens rettigheder, fordi de kan få en bredere adgang end brugeren.
• Edge Functions og serverkode: Gentag autorisationskontrollen, før en privilegeret nøgle bruges. “Kaldet kom fra vores frontend” er ikke en adgangsregel.
• Realtime: Test at abonnenter kun modtager de hændelser og rækker, som deres adgang tillader.

Gør Supabase-projektet muligt at drive og ændre

Sikker dataadgang skal kunne vedligeholdes, når en anden overtager projektet eller en ændring skal testes. Supabase anbefaler et lokalt workflow med migrationsfiler og separate projekter til staging og produktion, når løsningen har brug for flere miljøer. Det konkrete setup skal passe til appens risiko og teamets størrelse.

• Ejerskab: Organisation, projekt, domæne og betaling skal ligge på virksomhedens konti. Beskyt administrative konti med MFA, og undgå at én utilgængelig person er eneste ejer.
• Miljøer: Brug ikke produktionsbrugere og persondata som fri testplads. Hold URL'er, nøgler og data tydeligt adskilt.
• Migrationsfiler: Gem tabeller, grants, RLS-politikker og relevante funktioner i Git, så opsætningen kan gentages og gennemgås.
• Backup: Kontrollér hvad den valgte backup dækker. Databasebackup og Storage-filer er forskellige datatyper og skal begge indgå i en gendannelsesplan.
• Overvågning: Følg fejl, usædvanlig trafik, dyre forespørgsler og sikkerhedsfund. Aftal hvem der reagerer, og hvordan en farlig funktion begrænses.

Typiske fejl i en fungerende Supabase-app

• Frontendfilteret betragtes som sikkerhed: Brugeren kan ændre requestet og springe visningen over.
• RLS er slået til uden dækkende politikker og grants: Nogle handlinger er for åbne, mens andre fejler uden en forståelig årsag.
• Alle indloggede brugere behandles ens: Politikken skelner ikke mellem virksomheder, medlemskaber, roller eller den enkelte post.
• Secret eller service_role bruges for at få en fejl til at forsvinde: Fejlen skjules ved at omgå hele RLS-laget.
• Kun tabeller gennemgås: Storage, views, RPC-funktioner, Realtime eller en Edge Function åbner en anden vej til data.
• Kun tilladte handlinger testes: Ingen opdager, at en bruger også kan læse eller ændre en anden organisations data.
• Dashboardændringer lever kun i hukommelsen: En politik ændres direkte i produktion uden versionshistorik, review eller sikker gentagelse.

Tjekliste før kunder eller medarbejdere bruger appen

• ☐ Projektets browser-, server- og databaseadgange er kortlagt.
• ☐ Ingen secret, service_role-nøgle eller databaseforbindelse findes i klientkode, offentligt Git eller byggede filer.
• ☐ Alle tabeller og views i eksponerede schemas er gennemgået for grants og RLS.
• ☐ Der findes en adgangsmatrix for besøgende, brugere, organisationer, roller og administratorer.
• ☐ Select, insert, update og delete er vurderet særskilt.
• ☐ Bruger- og organisationstilhørsforhold kontrolleres i den betroede del af løsningen.
• ☐ Afviste forsøg er testet uden om brugerfladen for hver kritisk tabel og handling.
• ☐ Storage-buckets, views, databasefunktioner, Edge Functions og Realtime er med i gennemgangen.
• ☐ Administrative handlinger og serverkode bruger mindst mulig privilegeret adgang.
• ☐ RLS, grants og schemaændringer ligger i versionsstyrede migrationsfiler.
• ☐ Test og produktion har tydeligt adskilte projekter, nøgler og data, hvis risikoen kræver det.
• ☐ Virksomheden ejer Supabase-organisationen, har beskyttede administratorer og en dokumenteret gendannelsesvej.

Relaterede guides

Officielle kilder

Supabase ændrer løbende nøgler, defaults, dashboard og værktøjer. Kontrollér derfor den aktuelle dokumentation for jeres projekt, før I ændrer adgang eller produktion.

• Supabase Docs: API keys og forskellen på browser- og servernøgler
• Supabase Docs: Row Level Security
• Supabase Docs: Beskyt Data API med grants og RLS
• Supabase Docs: Test database og RLS-politikker
• Supabase Docs: Adgangskontrol i Storage
• Supabase Docs: Lokale miljøer, staging og migrations
• Supabase Docs: Production Checklist