Check access to each record
A customer signs in successfully and opens an invoice. The login verifies the account used to access the application. A separate decision must establish whether that person may read this particular invoice. The same applies to changing an order, downloading a document or exporting a report.
Consider a hypothetical customer portal. A user requests an invoice belonging to another company and the application returns it. The account is valid, but access to that invoice is unauthorized. OWASP describes this class of API weakness as broken object-level authorization. The business consequence can be exposure or alteration of another customer's information.
Make the access rule explicit
I would begin with a short access table: the person's role, the customer account, the record and the requested action. Reading an invoice, changing payment details and approving a refund need their own decisions. A role called administrator is too vague unless its permitted scope is clear.
Write down legitimate exceptions, including support staff who may work across customer accounts. Specify their authority and its limits. The aim is to enforce the agreed business rule wherever data is accessed. Hiding a button or making a document identifier difficult to guess cannot replace that check.
Follow the document through every route
The server must check permission for the requested record and action. Review the routes that return or change the data, including direct downloads and bulk exports. One protected screen does not demonstrate that every route applies the same rule.
For a report produced by a background job, I would examine whose authority the job uses, which customer records it includes and who can retrieve the finished file. A job's broad technical access should not become permission for its requester to receive every record.
Test the cases that must be refused
Use an agreed test environment with synthetic records and separate customer accounts. Confirm that each user can perform the intended actions on their own records. Then test the same actions on existing records outside their permitted scope, so the test examines access to a real record rather than a document that does not exist.
Check the result as well as the response message: no restricted content should be returned and no unauthorized change should occur. Include downloads and exports. Also test what happens after access is removed or a role changes. Keep these allowed and denied cases in the regression tests, using the documented access table as the expected result.
Give the rule an owner
Business owners should define who may perform each sensitive action. Engineering should identify where that decision is enforced; security and testing should verify it. During a technical review, I would ask for one traceable example connecting the business rule, the server-side check and the test result.
Start with one sensitive workflow, such as document delivery or a refund. Follow it through all its access routes before extending the review. This gives the team a concrete way to examine whether customer boundaries hold as the application evolves.