Role-Based Access Control (RBAC) toevoegen aan je app

Om role-based access control toe te voegen, geef je elke gebruiker een of meer rollen (bijvoorbeeld admin, editor, viewer), bepaal je welke acties elke rol mag uitvoeren, en controleer je die rechten op de server bij elk verzoek, niet alleen door knoppen te verbergen. Controleer ook dat het record waartoe toegang wordt gevraagd bij het account of team van de gebruiker hoort. Begin met een paar vaste rollen in je database, en test door te proberen rechtstreeks bij de data van een andere gebruiker te komen.

Authenticatie versus autorisatie

Twee woorden die vaak door elkaar worden gehaald:

• Authenticatie is wie ben jij? Inloggen. Zie hoe voeg je inloggen toe aan je app.
• Autorisatie is wat mag jij doen? Welke pagina's, records en acties een ingelogde gebruiker kan bereiken.

RBAC is de meest gebruikte manier van autorisatie. Het is belangrijk: vanaf september 2026 staat Broken Access Control op nummer 1 in de OWASP Top 10:2025, de veelgebruikte lijst van de ernstigste beveiligingsrisico's voor webapplicaties. Typische fouten zijn gebruikers die andermans records lezen door een ID in de URL te wijzigen, of gewone gebruikers die API-routes aanroepen die alleen voor admins bedoeld zijn.

Kies een model

In de praktijk combineren de meeste apps twee dingen: rollen voor het soort acties dat iemand mag uitvoeren, en eigenaarschap voor de records waarop die acties mogen. "Editors mogen posts bewerken" is een rolregel; "...posts in hun eigen werkruimte" is een eigenaarschapsregel. Je hebt beide nodig.

Begin eenvoudiger dan je denkt. Admin, member en viewer dekken al verrassend veel apps. Het is makkelijker om later een rol te splitsen dan tien rollen te ontwarren die niemand meer begrijpt.

Ontwerp de rollen voordat je code schrijft

Schrijf eerst een rechtentabel in gewone taal. Die dient als specificatie voor de AI en als testplan:

Bepaal ook de randgevallen: mag de laatste eigenaar weggaan? Kan een admin de eigenaar verwijderen? Wat ziet een verwijderde gebruiker?

Stap voor stap

1. Zorg eerst dat inloggen werkt

RBAC zit bovenop authenticatie. De server moet betrouwbaar weten wie elk verzoek doet, via een sessie of een geverifieerd token. Nooit via een gebruikers-ID dat de browser in de requestbody meestuurt.

2. Sla rollen op in de database

Voor een app met één team is een kolom role op de gebruikerstabel prima. Voor teams gebruik je een lidmaatschapstabel:

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

Laat gebruikers hun eigen rol nooit wijzigen via een gewone profielupdate. Rolwijzigingen lopen via een apart, op rechten gecontroleerd eindpunt.

3. Controleer rechten op de server, op één plek

Schrijf één helper, iets als can(user, 'projects.delete', project), en roep die aan in elke API-route, serveractie en achtergrondtaak die data leest of wijzigt. Eén centrale functie is makkelijker te beoordelen en te testen dan controles die verspreid door de code staan. Weiger standaard: als geen regel een actie toestaat, wordt ze geweigerd.

4. Scope elke query

Elke query naar teamdata moet het team bevatten: where organization_id = :currentOrg, niet alleen where id = :id. Zo voorkom je dat iemand /projects/123 in /projects/124 verandert en het project van een ander bedrijf ziet. Geef voor records van andere teams "niet gevonden" in plaats van "verboden", zodat je niet onthult dat ze bestaan.

5. Voeg databasebescherming toe waar het telt

Postgres row-level security (RLS) laat de database afdwingen welke rijen elke gebruiker ziet. Dat is essentieel als de browser rechtstreeks met de database praat (zoals bij sommige gehoste backends), en een nuttige tweede laag voor gevoelige tabellen anders.

6. Laat rollen zien in de interface

Verberg of schakel nu uit wat gebruikers niet mogen doen, zodat de app niet verwarrend is. Dit is alleen voor de gebruiksvriendelijkheid; de controles op de server beschermen echt.

7. Log gevoelige acties

Leg vast wie rollen heeft gewijzigd, data heeft verwijderd of records heeft geëxporteerd, en wanneer. Een auditlog helpt bij supportvragen en incidenten.

8. Test als een aanvaller

Log in met elke rol en probeer elke actie uit de rechtentabel. Probeer daarna de dingen die niet mogen werken: admin-API-routes aanroepen als viewer, ID's in URL's en verzoeken wijzigen, jezelf verwijderen als laatste eigenaar. Geautomatiseerde tests voor de rechtentabel zijn de moeite waard zodra de regels vaststaan.

Prompts die werken

Voeg role-based access control toe. Rollen per organisatie: owner, admin, member, viewer, opgeslagen in een lidmaatschapstabel. De rechten staan in deze tabel: [plak je tabel]. Maak één serverhelper can(user, action, resource), weiger standaard, en gebruik die in elke API-route. Scope elke query op organization_id. Verberg acties die de gebruiker niet mag uitvoeren in de UI, maar vertrouw daar nooit op voor beveiliging.

Controleer elke API-route en serverfunctie in deze app. Maak voor elk een lijst van welke data het leest of wijzigt, of het controleert of de gebruiker is ingelogd, of het de rol controleert, en of het de query scopt op zijn organisatie. Los ontbrekende controles op en laat me de lijst zien.

Voeg een alleen-admin-pagina /admin toe waar de eigenaar rollen van leden kan wijzigen. Voorkom dat de laatste eigenaar wordt verwijderd of gedegradeerd, log elke rolwijziging met wie die heeft gedaan en wanneer, en zorg dat het eindpunt voor rolwijzigingen iedereen die geen eigenaar is weigert.

Veelgemaakte fouten

• Rollen alleen in de frontend controleren. De API staat nog steeds open voor iedereen die die aanroept.
• Vertrouwen op ID's van de client, zoals een userId of role in de requestbody in plaats van uit de sessie.
• Niet-gescopete queries die alleen op record-ID ophalen.
• Rollen controleren op pagina's maar niet op API-routes, exports, bestandsdownloads of webhooks.
• Admin op basis van een e-mailadres dat in de code is vastgelegd (if email === 'me@...'). Dat vergeet je makkelijk en is lastig aan te passen.
• Te veel rollen te vroeg, die na zes maanden niemand meer kan uitleggen.
• Verouderde sessies: een gedegradeerde gebruiker houdt adminrechten tot hij uitlogt. Controleer rollen bij gevoelige acties in de database, of ververs ze.

RBAC-checklist

• Rechtentabel in gewone taal geschreven, randgevallen bepaald
• De server kent de gebruiker uit de sessie, nooit uit verzoekdata
• Rollen opgeslagen in de database; gebruikers kunnen hun eigen rol niet wijzigen
• Eén centrale rechtencontrole, standaard weigeren, gebruikt in elke route
• Elke query gescoped op de organisatie of het eigenaarschap van de gebruiker
• Row-level security waar de browser bij de database kan
• De UI verbergt wat gebruikers niet mogen (alleen voor gebruiksvriendelijkheid)
• Gevoelige acties gelogd
• Elke rol getest, inclusief rechtstreekse API-aanroepen en gewijzigde ID's

Toegangscontrole is één onderdeel van een langere lijst; de beveiligingschecklist voor met AI gebouwde apps behandelt de rest. Als je een tool bouwt voor je eigen personeel, laat hoe bouw je een interne tool zien waar rollen passen.

RBAC op Mythex

Mythex biedt geen ingebouwd inlog- of rollensysteem voor de gebruikers van je app. Je kiest een authenticatiebibliotheek of -provider, beschrijft de rollen, en de agent koppelt ze aan je code en de Postgres-database van je project (inloggen toevoegen aan je app). De werkruimterollen van Mythex zelf, zoals Eigenaar en Lid, bepalen wie je Mythex-projecten mag bewerken, niet wie de app die je publiceert mag gebruiken. Gebruik Plan-modus om de rechtentabel af te stemmen voordat je bouwt. Gebruik daarna de reviewprompt hierboven en test elke rol in Preview voordat je publiceert. De beveiligingsprompts in de documentatie zijn een nuttig vervolg.

Veelgestelde vragen