Sådan tilføjer du rollebaseret adgangskontrol (RBAC) til din app

For at tilføje rollebaseret adgangskontrol skal du give hver bruger en eller flere roller (f.eks. administrator, redaktør, læser), definere hvilke handlinger hver rolle må udføre, og tjekke disse rettigheder på serveren for hver forespørgsel — ikke blot ved at skjule knapper. Tjek også, at posten der tilgås, hører til brugerens konto eller team. Start med få faste roller i din database, og test ved at forsøge at nå en anden brugers data direkte.

Autentificering vs. autorisation

To ord der ofte blandes sammen:

• Autentificering er hvem er du? — at logge ind. Se sådan tilføjer du login til din app.
• Autorisation er hvad må du gøre? — hvilke sider, poster og handlinger en indlogget bruger kan nå.

RBAC er den mest almindelige måde at lave autorisation på. Det er vigtigt: pr. september 2026 er Broken Access Control nr. 1 i OWASP Top 10:2025, den bredt anvendte liste over de alvorligste sikkerhedsrisici for webapplikationer. Typiske fejl er brugere, der læser andre brugeres poster ved at ændre et ID i URL'en, eller almindelige brugere, der kalder API-ruter forbeholdt administratorer.

Vælg en model

I praksis kombinerer de fleste apps to ting: roller for hvilken type handlinger nogen kan tage, og ejerskab for hvilke poster de kan tage dem på. "Redaktører må redigere opslag" er en rollegel; "…opslag i deres eget workspace" er en ejerskabsregel. Du har brug for begge.

Start enklere, end du tror. Administrator, medlem og læser dækker et overraskende antal apps. Det er nemmere at dele en rolle senere end at udrede ti roller, ingen forstår.

Design rollerne før du skriver kode

Skriv først en rettighedstabel i almindeligt sprog. Den fungerer både som specifikation til AI'en og som din testplan:

Beslut også kanttilfældene: Må den sidste ejer forlade teamet? Kan en administrator fjerne ejeren? Hvad ser en fjernet bruger?

Trin for trin

1. Få et fungerende login først

RBAC ligger oven på autentificering. Serveren skal pålideligt vide, hvem der står bag hver forespørgsel, ud fra en session eller et verificeret token — aldrig fra et bruger-ID, som browseren sender i request-body'en.

2. Gem roller i databasen

Til en app med ét team er en role-kolonne på brugere fin. Til teams bruger du en medlemstabel:

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)
);

Lad aldrig brugere selv sætte deres rolle via en almindelig profilopdatering. Rolleændringer skal gå gennem et dedikeret, rettighedstjekket endepunkt.

3. Tjek rettigheder på serveren, ét sted

Skriv én hjælpefunktion — noget i stil med can(user, 'projects.delete', project) — og kald den i hver API-rute, server action og baggrundsopgave, der læser eller ændrer data. Én central funktion er lettere at gennemgå og teste end tjek spredt rundt i koden. Afvis som standard: hvis ingen regel tillader en handling, bliver den afvist.

4. Afgræns hver forespørgsel

Hver forespørgsel efter teamdata skal inkludere teamet: where organization_id = :currentOrg, ikke bare where id = :id. Det er det, der forhindrer nogen i at ændre /projects/123 til /projects/124 og se en anden virksomheds projekt. Returnér "ikke fundet" frem for "forbudt" for poster i andre teams, så du ikke afslører at de findes.

5. Tilføj beskyttelse i databasen, hvor det tæller

Postgres row-level security (RLS) lader databasen håndhæve, hvilke rækker hver bruger kan se. Det er afgørende, hvis browseren taler direkte med databasen (som ved nogle hostede backends), og et nyttigt ekstra lag for følsomme tabeller ellers.

6. Afspejl roller i grænsefladen

Nu skjuler eller deaktiverer du det, brugerne ikke må gøre, så appen ikke bliver forvirrende. Dette er kun for brugervenlighed; det er serverens tjek, der beskytter.

7. Log følsomme handlinger

Registrér hvem der ændrede roller, slettede data eller eksporterede poster, og hvornår. Et revisionslog hjælper med supportspørgsmål og hændelser.

8. Test som en angriber

Log ind som hver rolle, og prøv hver handling i rettighedstabellen. Prøv derefter de ting, der ikke må virke: kald administratorruter som læser, ændr ID'er i URL'er og forespørgsler, fjern dig selv som den sidste ejer. Automatiserede tests for rettighedstabellen er værd at skrive, når reglerne er faste.

Prompts der virker

Tilføj rollebaseret adgangskontrol. Roller pr. organisation: owner, admin, member, viewer, gemt i en memberships-tabel. Rettighederne står i denne tabel: [indsæt din tabel]. Opret én server-side hjælpefunktion can(user, action, resource), afvis som standard, og brug den i alle API-ruter. Afgræns hver forespørgsel med organization_id. Skjul handlinger brugeren ikke må udføre i grænsefladen, men stol aldrig på det for sikkerhedens skyld.

Gennemgå hver API-rute og server-funktion i denne app. For hver, list hvilke data den læser eller ændrer, om den tjekker at brugeren er logget ind, om den tjekker rollen, og om den afgrænser forespørgslen til brugerens organisation. Ret dem der mangler et tjek, og vis mig listen.

Tilføj en side /admin, der kun er for ejere, hvor ejeren kan ændre medlemmers roller. Forhindr at fjerne eller nedgradere den sidste ejer, log hver rolleændring med hvem der lavede den og hvornår, og sørg for at rolleændrings-endepunktet afviser alle, der ikke er ejer.

Almindelige fejl

• At tjekke roller kun i frontenden. API'en er stadig åben for enhver, der kalder den.
• At stole på ID'er fra klienten — et userId eller en role i request-body'en i stedet for fra sessionen.
• Ikke-afgrænsede forespørgsler der henter efter post-ID alene.
• Roller tjekket på sider men ikke på API-ruter, eksporter, filhentninger eller webhooks.
• Admin ud fra en e-mailadresse hårdkodet i koden (if email === 'me@...'), som er let at glemme og svær at ændre.
• For mange roller for tidligt, som ingen kan forklare seks måneder senere.
• Forældede sessioner: en nedgraderet bruger beholder administratorrettigheder, indtil de logger ud. Tjek roller fra databasen, eller opdatér dem, ved følsomme handlinger.

Tjekliste for RBAC

• Rettighedstabel skrevet i almindeligt sprog, kanttilfælde besluttet
• Serveren kender brugeren fra sessionen, aldrig fra request-data
• Roller gemt i databasen; brugere kan ikke ændre deres egne
• Ét centralt rettighedstjek, afvis som standard, brugt i alle ruter
• Hver forespørgsel afgrænset til brugerens organisation eller ejerskab
• Row-level security hvor browseren kan nå databasen
• Grænsefladen skjuler det, brugerne ikke må gøre (kun for brugervenlighed)
• Følsomme handlinger logget
• Hver rolle testet, inklusive direkte API-kald og ændrede ID'er

Adgangskontrol er ét punkt på en længere liste; sikkerhedstjeklisten for AI-byggede apps dækker resten. Hvis du bygger et værktøj til dit eget personale, viser sådan bygger du et internt værktøj, hvor roller passer ind.

RBAC på Mythex

Mythex tilbyder ikke et indbygget login- eller rollesystem til din apps brugere. Du vælger et auth-bibliotek eller en udbyder og beskriver rollerne, og agenten kobler dem ind i din kode og dit projekts Postgres-database (tilføj login til din app). Mythex' egne workspace-roller, såsom Owner og Member, styrer, hvem der må redigere dine Mythex-projekter, ikke hvem der må bruge den app, du udgiver. Brug Plan-tilstand til at blive enige om rettighedstabellen, før du bygger, og brug derefter gennemgangsprompten ovenfor og test hver rolle i Preview, før du udgiver. Dokumentationens sikkerhedsprompts er en god opfølgning.

Spørgsmål