Slik legger du til rollebasert tilgangskontroll (RBAC) i appen

For å legge til rollebasert tilgangskontroll gir du hver bruker én eller flere roller (for eksempel admin, redaktør, leser), definerer hvilke handlinger hver rolle kan utføre, og sjekker disse tillatelsene på serveren for hver forespørsel, ikke bare ved å skjule knapper. Kontroller også at posten som åpnes, tilhører brukerens konto eller team. Start med noen få faste roller i databasen din, og test ved å prøve å nå en annen brukers data direkte.

Autentisering vs. autorisasjon

To ord som ofte blandes sammen:

• Autentisering handler om hvem er du?: innlogging. Se slik legger du til innlogging i appen din.
• Autorisasjon handler om hva har du lov til å gjøre?: hvilke sider, poster og handlinger en innlogget bruker kan nå.

RBAC er den vanligste måten å gjøre autorisasjon på. Det er viktig: per september 2026 er Broken Access Control nummer 1 på OWASP Top 10:2025, den mye brukte listen over de alvorligste sikkerhetsrisikoene for webapplikasjoner. Typiske feil er at brukere leser andres poster ved å endre en ID i URL-en, eller at vanlige brukere kaller API-ruter som bare er ment for admin.

Velg en modell

I praksis kombinerer de fleste apper to ting: roller for hva slags handlinger noen kan ta, og eierskap for hvilke poster de kan utføre dem på. «Redaktører kan redigere innlegg» er en regel om rolle. «…innlegg i deres egen arbeidsflate» er en regel om eierskap. Du trenger begge.

Start enklere enn du tror. Admin, medlem og leser dekker et overraskende antall apper. Det er lettere å dele en rolle senere enn å få orden på ti roller ingen forstår.

Design rollene før du skriver kode

Skriv først en tillatelsestabell i vanlig språk. Den fungerer både som spesifikasjon for KI-en og som testplan:

Bestem også grensetilfellene: kan den siste eieren forlate teamet? Kan en admin fjerne eieren? Hva ser en fjernet bruker?

Steg for steg

1. Ha en fungerende innlogging først

RBAC ligger oppå autentisering. Serveren må pålitelig vite hvem som gjør hver forespørsel, fra en sesjon eller et verifisert token, og aldri fra en bruker-ID som nettleseren sender i forespørselens innhold.

2. Lagre roller i databasen

For en app med ett team er en role-kolonne på brukere fin. For team bruker du en medlemstabell:

create table memberships (
  user_id uuid references users(id),
  organization_id uuid references organizations(id),
  role text not null check (role in ('owner','admin','member','viewer')),
  primary key (user_id, organization_id)
);

La aldri brukere sette sin egen rolle gjennom en vanlig profiloppdatering. Rolleendringer går via et eget endepunkt med tillatelseskontroll.

3. Sjekk tillatelser på serveren, på ett sted

Skriv én hjelpefunksjon, noe slikt som can(user, 'projects.delete', project), og kall den i hver API-rute, server action og bakgrunnsjobb som leser eller endrer data. Én sentral funksjon er enklere å gjennomgå og teste enn sjekker spredt rundt i koden. Nekt som standard: hvis ingen regel tillater en handling, avvises den.

4. Avgrens hver spørring

Hver spørring etter teamdata bør inkludere teamet: where organization_id = :currentOrg, ikke bare where id = :id. Det er dette som hindrer at noen endrer /projects/123 til /projects/124 og ser et annet selskaps prosjekt. Returner «ikke funnet» i stedet for «forbudt» for poster i andre team, slik at du ikke avslører at de finnes.

5. Legg til databasebeskyttelse der det betyr noe

Postgres radnivå-sikkerhet (RLS) lar databasen håndheve hvilke rader hver bruker kan se. Det er viktig hvis nettleseren snakker direkte med databasen (slik som i noen hostede backender), og et nyttig ekstra lag for sensitive tabeller ellers.

6. Speil rollene i grensesnittet

Nå skjuler eller deaktiverer du det brukerne ikke kan gjøre, slik at appen ikke blir forvirrende. Dette er kun for brukervennlighet. Det er sjekkene på serveren som faktisk beskytter.

7. Logg sensitive handlinger

Registrer hvem som endret roller, slettet data eller eksporterte poster, og når. En revisjonslogg hjelper med støtteforespørsler og hendelser.

8. Test som en angriper

Logg inn som hver rolle og prøv hver handling i tillatelsestabellen. Prøv så det som ikke skal fungere: kall admin-API-ruter som leser, endre ID-er i URL-er og forespørsler, fjern deg selv som siste eier. Automatiske tester for tillatelsestabellen er verdt å skrive når reglene har satt seg.

Ledetekster som fungerer

Legg til rollebasert tilgangskontroll. Roller per organisasjon: owner, admin, member, viewer, lagret i en medlemstabell. Tillatelsene står i denne tabellen: [lim inn tabellen din]. Lag én serverside hjelpefunksjon can(user, action, resource), nekt som standard, og bruk den i hver API-rute. Avgrens hver spørring med organization_id. Skjul handlinger brukeren ikke kan utføre i grensesnittet, men stol aldri på det for sikkerhet.

Gå gjennom hver API-rute og serverfunksjon i denne appen. For hver: list opp hvilke data den leser eller endrer, om den sjekker at brukeren er innlogget, om den sjekker rollen deres, og om den avgrenser spørringen til organisasjonen deres. Fiks de som mangler en sjekk, og vis meg listen.

Legg til en admin-side bare for eieren, der eieren kan endre roller for medlemmene. Hindre at den siste eieren fjernes eller nedgraderes, logg hver rolleendring med hvem som gjorde den og når, og sørg for at endepunktet for rolleendring avviser alle som ikke er eier.

Vanlige feil

• Sjekke roller bare i frontend. API-et er fortsatt åpent for alle som kaller det.
• Stole på ID-er fra klienten, for eksempel en userId eller role i forespørselens innhold i stedet for i sesjonen.
• Uavgrensede spørringer som henter etter rad-ID alene.
• Roller sjekket på sider, men ikke på API-ruter, eksporter, filnedlastinger eller webhooks.
• Admin etter e-postadresse hardkodet i koden (if email === 'me@...'), som er lett å glemme og vanskelig å endre.
• For mange roller for tidlig, som ingen kan forklare seks måneder senere.
• Utdaterte sesjoner: en nedgradert bruker beholder adminrettigheter til hen logger ut. Sjekk roller fra databasen, eller oppdater dem, ved sensitive handlinger.

Sjekkliste for RBAC

• Tillatelsestabell skrevet i vanlig språk, og grensetilfeller avgjort
• Serveren kjenner brukeren fra sesjonen, aldri fra forespørselsdata
• Roller lagret i databasen; brukere kan ikke endre sine egne
• Én sentral tillatelsessjekk, nekt som standard, brukt i hver rute
• Hver spørring avgrenset til brukerens organisasjon eller eierskap
• Radnivå-sikkerhet der nettleseren kan nå databasen
• Grensesnittet skjuler det brukerne ikke kan gjøre (kun for brukervennlighet)
• Sensitive handlinger logget
• Hver rolle testet, også direkte API-kall og endrede ID-er

Tilgangskontroll er ett punkt på en lengre liste. Sikkerhetssjekklisten for KI-bygde apper dekker resten. Hvis du bygger et verktøy for dine egne ansatte, viser slik bygger du et internt verktøy hvor roller passer inn.

RBAC på Mythex

Mythex tilbyr ikke et innebygd innloggings- eller rollesystem for brukerne av appen din. Du velger et autentiseringsbibliotek eller en leverandør og beskriver rollene, og agenten kobler dem inn i koden din og i prosjektets Postgres-database (legg til innlogging i appen din). Mythex sine egne arbeidsområderoller, som Eier og Medlem, styrer hvem som kan redigere dine Mythex-prosjekter, ikke hvem som kan bruke appen du publiserer. Bruk planmodus for å bli enige om tillatelsestabellen før du bygger, bruk gjennomgangsledetekstene over, og test hver rolle i forhåndsvisningen før du publiserer. Dokumentasjonens sikkerhetsledetekster er en nyttig oppfølging.

Spørsmål