Dat iemand kan inloggen, bewijst niet dat diegene bevoegd is om alle gegevens in de applicatie te bekijken of te wijzigen. Authenticatie identificeert de gebruiker; autorisatie bepaalt wat diegene mag doen, op welke resource en onder welke voorwaarden. Een route kan een geldige sessie vereisen en toch iemand toestaan de bestelling van een ander account te bekijken als de relatie tussen gebruiker en resource niet wordt gecontroleerd.
Autorisatietests in PHP moeten die grens controleren via de toegangspunten die de applicatie gebruikt: bijvoorbeeld een HTTP-verzoek naar een webroute of API. Het doel is niet om te testen hoe een framework zijn beleidsregels implementeert, maar om het waarneembare gedrag te bevestigen: wie wat mag doen, wanneer een verzoek wordt geweigerd en welke gegevens ongewijzigd blijven.
Toegangsregels omzetten in een matrix
Druk de regels uit voordat je tests schrijft aan de hand van vier elementen: actor, actie, resource en context. De context omvat voorwaarden die de bevoegdheid wijzigen, zoals lidmaatschap van dezelfde organisatie, eigenaar zijn van het record of een bepaalde status hebben. Deze structuur voorkomt dat autorisatie wordt teruggebracht tot een lijst met rollen.
- Actor: anonieme gebruiker, lid, verantwoordelijke of beheerder.
- Actie: bekijken, aanmaken, bewerken, verwijderen of goedkeuren.
- Resource: een bestelling, document, account of ander beschermd object.
- Context: eigenaar, organisatie, status van de resource of geldige relatie.
Een regel kan bijvoorbeeld toestaan dat een lid diens eigen bestellingen bekijkt, terwijl een verantwoordelijke de bestellingen van diens organisatie kan bekijken. Een beheerder kan ruimere toegang hebben, afhankelijk van de werkelijke productregels. De matrix zet elke zakelijke regel om in testbare gevallen en maakt ontbrekende combinaties zichtbaar.
Je hoeft niet elke denkbare permutatie te testen. Geef prioriteit aan vertrouwensgrenzen: een gebruiker zonder sessie, twee gebruikers van dezelfde organisatie, gebruikers van verschillende organisaties, iemand met een bevoorrechte rol en een resource die niet van diegene is. Voeg speciale contexten toe die de beslissing wijzigen, zoals een gearchiveerde bestelling als daarvoor andere rechten gelden dan voor een actieve bestelling.
Representatieve integratiescenario's voorbereiden
Bereid de testgegevens expliciet en beperkt voor. Een typische test kan twee organisaties aanmaken, in elke organisatie een gebruiker en een resource die aan een van de organisaties is gekoppeld. Authenticeer vervolgens als de gebruiker die toegang probeert te krijgen en stuur een verzoek naar de openbare route van de applicatie met de identificatie van de resource. Zo worden de toegang, authenticatie, autorisatie en respons gezamenlijk getest.
Neem voor elke belangrijke regel ten minste één toegestaan en één geweigerd geval op. Als de eigenaar van een resource deze mag bewerken, controleer dan dat de bewerking met toestemming slaagt en dat een andere gebruiker deze niet kan uitvoeren. Een positief geval is essentieel: een suite die alleen afwijzingen verwacht, kan slagen terwijl de applicatie ook gebruikers blokkeert die wel rechten hebben.
Controleer ook of de resource niet bestaat. De respons op een onbekende identificatie kan verschillen van de respons op een bestaande resource waarvoor de gebruiker geen rechten heeft. Sommige applicaties geven een ‘niet gevonden’-respons om het bestaan van de resource niet prijs te geven; andere melden dat de toegang verboden is. De test moet het bewuste productbeleid weerspiegelen, geen universele conventie opleggen.
Gebruik factories, fixture-builders of testhelpers die geldige en leesbare toestanden opleveren. Vermijd afhankelijkheid van vaste identificaties, uitvoervolgorde of gedeelde gegevens die door een andere test kunnen worden gewijzigd. Als persistentie deel uitmaakt van het gedrag dat je wilt controleren, verifieer dan het resultaat in de database met de gebruikelijke tools van het project; ga er niet van uit dat een succesvolle respons op zichzelf de juiste toestand garandeert.
Isolatie tussen gebruikers en organisaties testen
Isolatie verdient eigen testgevallen, omdat fouten vaak ontstaan wanneer een identificatie in de URL of request body wordt gewijzigd. Maak een resource voor een account aan en probeer deze vanuit een andere identiteit te bekijken, bewerken of verwijderen. Herhaal de controle tussen organisaties wanneer de applicatie gegevens per bedrijf afschermt. Test bij kritieke bewerkingen elke actie: dat een leesbewerking beschermd is, bewijst niet dat downloaden, exporteren of bijwerken dat ook is.
Om niet de hele suite te dupliceren, deel je de gemeenschappelijke voorbereiding en parametriseer je alleen de dimensies die de regel uitdrukken. Een lijst met actor-resourceparen kan bijvoorbeeld aangeven welke combinaties zijn toegestaan. Behoud concrete namen voor de gevallen: ‘lid van een andere organisatie mag de bestelling niet bewerken’ zegt meer dan een ondoorzichtige reeks booleans. Splits scenario's op wanneer de methode, route of verwachte effecten verschillen.
Test niet elke combinatie van rollen en resources als veel daarvan geen afzonderlijke regels vertegenwoordigen. Breng in plaats daarvan onderbouwde equivalenties in kaart en behoud expliciete gevallen voor uitzonderingen en grenzen. Ga er bij hiërarchische rollen niet van uit dat de ene rol automatisch alle rechten van een andere erft: controleer de daadwerkelijke regel die het product definieert.
Responsen en neveneffecten controleren
Controleer bij een afwijzing zowel de respons als dat de beschermde bewerking niet is uitgevoerd. Afhankelijk van de interface kan de respons een redirect, een status voor ongeautoriseerde of verboden toegang, of een respons voor een niet-gevonden resource zijn. Controleer het relevante contract — status, formaat en, indien van belang, bericht — zonder de test onnodig afhankelijk te maken van presentatiedetails.
Controleer bij een geweigerde update dat gevoelige velden ongewijzigd zijn. Controleer bij een verwijdering dat het record nog bestaat. Controleer bij een bewerking die een factuur, melding of event genereert dat ook dat effect niet heeft plaatsgevonden. Assertions moeten de voor het bedrijf belangrijke effecten afdekken, niet alleen de HTTP-statuscode.
Een niet-geautoriseerd verzoek mag ook geen gedeeltelijke wijzigingen veroorzaken. Als de flow meerdere bewerkingen uitvoert, controleer dan dat de afwijzing vóór de mutaties plaatsvindt of dat de transactie het systeem in een consistente toestand achterlaat. Je hoeft geen private methoden te inspecteren om dit aan te tonen: observeer de respons en de opgeslagen gegevens of effecten.
Tests bestand houden tegen implementatiewijzigingen
Integratietests moeten verlopen via een stabiele interface van de applicatie, zoals een route en een verzoek met een identiteit die via de beschikbare testmechanismen is geauthenticeerd. Roep niet rechtstreeks een interne policyklasse aan als je de daadwerkelijke toegang tot een resource wilt valideren: daardoor kunnen de routedefinitie, middleware of de manier waarop het object wordt geladen buiten de test vallen.
Maak de suite tegelijkertijd niet tot een kopie van de hele applicatie. Test het autorisatiecontract op representatieve toegangspunten en reserveer unittests voor zuivere regels die veel contextgevallen vereisen. Deze combinatie helpt fouten te lokaliseren: een regeltest kan één voorwaarde isoleren, terwijl de integratietest bevestigt dat die regel de blootgestelde flow beschermt.
Controleer bij wijzigingen aan rollen, routes of beleidsregels eerst de matrix voordat je verwachtingen aanpast. Een test die alleen wordt bijgewerkt om de nieuwe uitkomst te accepteren, kan een onbedoelde uitbreiding van rechten verhullen. Leg vast waarom de regel is gewijzigd, bepaal welke actors toegang krijgen of verliezen en voeg gevallen toe die de nieuwe grenzen beschermen.
Checklist voor het beoordelen van een wijziging
- Zijn actor, actie, resource en context gedefinieerd?
- Is er voor de gewijzigde regel ten minste één toegestaan en één geweigerd scenario?
- Wordt de toegang tussen gebruikers of gegevensdomeinen getest waar dat van toepassing is?
- Worden een niet-bestaande resource en het gekozen beleid om informatie niet prijs te geven getest?
- Verloopt het verzoek via het toegangspunt dat beschermd moet zijn?
- Wordt gecontroleerd dat een afwijzing geen gegevens wijzigt of neveneffecten veroorzaakt?
- Zijn de testgegevens geïsoleerd, leesbaar en reproduceerbaar?
- Weerspiegelen de verwachtingen een productbeslissing en geen toevallig frameworkdetail?
Een nuttige suite bewijst niet in abstracte zin dat er ‘rechten zijn’: ze toont aan dat relevante combinaties werken en dat niet-geautoriseerde combinaties de grens niet overschrijden. Door die matrix te combineren met concrete integratietests, kun je wijzigingen in de toegang gemakkelijker beoordelen zonder de beveiliging aan een specifieke interne implementatie te koppelen.
