Access control is where most real breaches of web applications begin, because it is the one thing a framework cannot do for you: only the application knows who should see what.
Two accounts, every time
The method is dull and effective. Create two accounts in each role — two customers, two administrators, a customer and a staff member — then take every request one can make and replay it as the other, changing only the identifier. Watch for: full responses, partial responses, different error codes, and timing differences that reveal existence.
Where to look
Object references. Any identifier in a URL, body, header or cookie. Sequential integers make the test obvious; UUIDs make it harder, not safer, since identifiers leak through exports, notifications and search.
Functions. Endpoints that the interface only shows to administrators but the server does not check. Enumerate from the client bundle, the API schema, and old versions of the API that nobody retired.
Fields. Mass assignment: sending role=admin or account_id=other in an update that the server copies wholesale.
Tenancy. In multi-tenant systems, the tenant identifier must be enforced server-side on every query, never taken from the request.
What good looks like
Authorisation decided in one place, close to the data, from the authenticated identity — never from a parameter the client controls. Then the test above returns 403 every time, which is the only result worth having.