Antwoord.

Handmatige toegangstest en rollen stellen ons in staat te controleren dat verschillende soorten gebruikers het juiste niveau van toegang hebben tot de functionaliteit en gegevens van de applicatie.

Geschiedenis van de vraag

Naarmate het aantal gebruikers en hun werkscenario's toenam, kregen zelfs eenvoudige applicaties een rolmodel. Fouten in het toegangsrecht leidden vaak tot ernstige datalekken of beperkingen van bedrijfsoperaties. Dit resulteerde in de noodzaak om rollen handmatig grondig te testen.

Probleem

het missen van fouten in de toegang tot gevoelige gegevens;
onjuiste rolinstelling die gebruikers in staat stelt ongeoorloofde handelingen uit te voeren (bijvoorbeeld toegang tot beheerdersfuncties voor gewone gebruikers);
moeilijkheden bij het controleren van gecombineerde rollen of niet-standaard toegangsscenario's.

Oplossing

Documenteer alle bestaande rollen en de bijbehorende acties voor elke rol;
Vorm testsets voor elke rol, inclusief voorwaardelijke overlaps van rollen;
Controleer de toegang niet alleen tot functies, maar ook tot verschillende delen van gegevens (CRUD);
Valideer zowel directe toegang (via de UI) als toegangspogingen via directe links of API.

Belangrijke kenmerken:

Omvattende dekking van scenario's: elke type gebruiker moet worden gecontroleerd in alle mogelijke rollen en acties;
Testing van grens- en gecombineerde rollen: fouten manifesteren zich vaak bij overlapping van bevoegdheden van verschillende rollen;
Controle op het omzeilen van standaardinterfaces: testen van directe toegang tot pagina's/acties waarvoor de gebruiker officieel geen rechten heeft.

Vragen met een valstrik.

Is het genoeg om alleen de basisrollen te testen (zoals "Administrator" en "Gebruiker")?

Nee. Het zijn juist de tussentijdse, zelden gebruikte en gecombineerde rollen waar vaak defecten zijn verborgen.

Is UI-beperking (verborgen knoppen en elementen) voldoende voor veiligheid?

Nee. UI-controle beschermt niet tegen pogingen tot directe toegang per adres of via API; rechten moeten op serverniveau worden beperkt.

Moet toegang tot verschillende kanalen van de applicatie worden getest (bijvoorbeeld zowel via web als via mobiele applicatie)?

Absoluut. Vaak leidt de variatie in implementatie tot verschillen in gedrag en fouten in toegangsbeperkingen.

Typische fouten en anti-patronen

Alleen standaardrollen testen
Uitsluitend op de externe interface richten, zonder serverbeperkingen te valideren
Negeren van niet-standaard en gecombineerde rollen

Voorbeeld uit het leven

Negatief geval

Alleen de UI en slechts drie basisrollen werden getest. Als gevolg hiervan kregen gebruikers met een niet-standaard combinatie van rollen toegang tot beheerdersfuncties via directe link.

Pluspunten:

Snelle test
Eenvoudig proces

Minpunten:

Kritieke kwetsbaarheid ontdekt in productie
Schending van veiligheid en vertrouwen van gebruikers

Positief geval

Voor de tests werden testgebruikers met verschillende combinaties van rollen aangemaakt, en er werd een audit van de API en directe toegang uitgevoerd. Fouten werden ontdekt en gecorrigeerd voordat de release.