Så lägger du till rollbaserad åtkomstkontroll (RBAC) i din app

För att lägga till rollbaserad åtkomstkontroll ger du varje användare en eller flera roller (till exempel admin, redaktör, läsare), definierar vilka åtgärder varje roll får utföra och kontrollerar dessa behörigheter på servern för varje förfrågan, inte bara genom att dölja knappar. Kontrollera också att posten som öppnas tillhör användarens konto eller team. Börja med några fasta roller i din databas, och testa genom att försöka nå en annan användares data direkt.

Autentisering kontra auktorisering

Två ord som ofta blandas ihop:

• Autentisering är vem är du? — att logga in. Se så lägger du till inloggning i din app.
• Auktorisering är vad får du göra? — vilka sidor, poster och åtgärder en inloggad användare kan nå.

RBAC är det vanligaste sättet att göra auktorisering på. Det är viktigt: per september 2026 är Broken Access Control nummer ett i OWASP Top 10:2025, den allmänt använda listan över de allvarligaste säkerhetsriskerna i webbappar. Typiska fel är att användare läser andra användares poster genom att ändra ett ID i URL:en, eller att vanliga användare anropar API-rutter som bara är till för admin.

Välj en modell

I praktiken kombinerar de flesta appar två saker: roller för vilken typ av åtgärder någon får utföra, och ägande för vilka poster de får utföra dem på. "Redaktörer får redigera inlägg" är en rollregel; "…inlägg i deras egen arbetsyta" är en ägarregel. Du behöver båda.

Börja enklare än du tror. Admin, medlem och läsare räcker för förvånansvärt många appar. Det är lättare att dela upp en roll senare än att reda ut tio roller som ingen förstår.

Designa rollerna innan du skriver kod

Skriv en behörighetstabell i vanligt språk först. Den fungerar både som specifikation för AI:n och som din testplan:

Bestäm också gränsfallen: kan den sista ägaren lämna? Kan en admin ta bort ägaren? Vad ser en borttagen användare?

Steg för steg

1. Ha fungerande inloggning först

RBAC ligger ovanpå autentiseringen. Servern måste på ett tillförlitligt sätt veta vem som gör varje förfrågan, från en session eller en verifierad token, aldrig från ett användar-ID som webbläsaren skickar i förfrågans brödtext.

2. Lagra roller i databasen

För en app med ett enda team räcker en kolumn role på användare. För team använder 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)
);

Låt aldrig användare sätta sin egen roll via en vanlig profiluppdatering. Rolländringar går via en särskild endpoint med behörighetskontroll.

3. Kontrollera behörigheter på servern, på ett ställe

Skriv en hjälpfunktion, till exempel can(user, 'projects.delete', project), och anropa den i varje API-rutt, serveråtgärd och bakgrundsjobb som läser eller ändrar data. En central funktion är lättare att granska och testa än kontroller utspridda i koden. Neka som standard: om ingen regel tillåter en åtgärd, nekas den.

4. Avgränsa varje fråga

Varje fråga efter teamdata ska inkludera teamet: where organization_id = :currentOrg, inte bara where id = :id. Det är detta som hindrar någon från att ändra /projects/123 till /projects/124 och se ett annat företags projekt. Svara "hittades inte" i stället för "förbjudet" för poster i andra team, så att du inte avslöjar att de finns.

5. Lägg till skydd på databasnivå där det gör störst nytta

Postgres radnivåsäkerhet (RLS) låter databasen avgöra vilka rader varje användare kan se. Den är avgörande om webbläsaren pratar direkt med databasen (som med vissa hostade backends), och ett användbart andra lager för känsliga tabeller annars.

6. Spegla roller i gränssnittet

Dölj eller inaktivera nu det användare inte får göra, så att appen inte blir förvirrande. Detta är bara för användbarhetens skull; det är serverkontrollerna som skyddar.

7. Logga känsliga åtgärder

Spara vem som ändrade roller, tog bort data eller exporterade poster, och när. En granskningslogg hjälper vid supportfrågor och incidenter.

8. Testa som en angripare

Logga in som varje roll och prova varje åtgärd i behörighetstabellen. Prova sedan sådant som inte ska fungera: anropa admin-API-rutter som läsare, ändra ID:n i URL:er och förfrågningar, ta bort dig själv som sista ägare. Automatiserade tester för behörighetstabellen är värda att skriva när reglerna har satt sig.

Prompter som fungerar

Lägg till rollbaserad åtkomstkontroll. Roller per organisation: owner, admin, member, viewer, lagrade i en medlemstabell. Behörigheterna finns i denna tabell: [klistra in din tabell]. Skapa en enda serverhjälpfunktion can(user, action, resource), neka som standard, och använd den i varje API-rutt. Avgränsa varje fråga med organization_id. Dölj åtgärder som användaren inte kan utföra i gränssnittet, men förlita dig aldrig på det för säkerheten.

Granska varje API-rutt och serverfunktion i den här appen. För varje en, lista vilken data den läser eller ändrar, om den kontrollerar att användaren är inloggad, om den kontrollerar deras roll och om den avgränsar frågan till deras organisation. Åtgärda alla som saknar en kontroll och visa mig listan.

Lägg till en sida /admin enbart för admin där ägaren kan ändra medlemmars roller. Förhindra att den sista ägaren tas bort eller degraderas, logga varje rolländring med vem som gjorde den och när, och se till att endpointen för rolländring avvisar alla som inte är ägare.

Vanliga misstag

• Att bara kontrollera roller i gränssnittet. API:et är fortfarande öppet för vem som helst som anropar det.
• Att lita på ID:n från klienten, till exempel ett userId eller role i förfrågans brödtext i stället för i sessionen.
• Oavgränsade frågor som hämtar efter enbart post-ID.
• Roller kontrollerade på sidor men inte på API-rutter, exporter, filnedladdningar eller webhooks.
• Admin via e-postadress hårdkodad i koden (if email === 'me@...'), vilket är lätt att glömma och svårt att ändra.
• För många roller för tidigt, som ingen kan förklara sex månader senare.
• Inaktuella sessioner: en degraderad användare behåller admin-rättigheter tills de loggar ut. Kontrollera roller från databasen, eller uppdatera dem, vid känsliga åtgärder.

Checklista för RBAC

• Behörighetstabell skriven i vanligt språk, gränsfall avgjorda
• Servern känner till användaren från sessionen, aldrig från förfrågningsdata
• Roller lagrade i databasen; användare kan inte ändra sina egna
• En central behörighetskontroll, neka som standard, använd i varje rutt
• Varje fråga avgränsad till användarens organisation eller ägande
• Radnivåsäkerhet där webbläsaren kan nå databasen
• Gränssnittet döljer det användare inte kan göra (endast för användbarheten)
• Känsliga åtgärder loggade
• Varje roll testad, inklusive direkta API-anrop och ändrade ID:n

Åtkomstkontroll är en punkt på en längre lista; säkerhetschecklistan för AI-byggda appar täcker resten. Om du bygger ett verktyg för din egen personal visar så bygger du ett internt verktyg var roller passar in.

RBAC på Mythex

Mythex tillhandahåller inget inbyggt inloggnings- eller rollsystem för din apps användare. Du väljer ett autentiseringsbibliotek eller en leverantör och beskriver rollerna, och agenten kopplar in dem i din kod och i projektets Postgres-databas (lägg till inloggning i din app). Mythex egna arbetsytroller, som Owner och Member, styr vem som kan redigera dina Mythex-projekt, inte vem som kan använda appen du publicerar. Använd planeringsläget för att komma överens om behörighetstabellen innan du bygger, använd sedan granskningsprompten ovan och testa varje roll i förhandsgranskningen innan du publicerar. Dokumentationens säkerhetsprompter är en användbar uppföljning.

Frågor