Testing Web App Access with a User Permission Matrix

A button disappearing from the screen does not prove that an action is protected. When planning a web app, a business owner needs to explain who may do what, and to which records. A role matrix makes this discussion concrete before testing begins.

The example below uses a fictional work tracking application. Adapt the permission decisions to your own process: identical role names can carry different responsibilities in different applications.

Start with consequential actions

Write actions as verbs: view a job, create a note, change its assignee, export a list, and delete a job. Separate actions that look similar. Editing your own note does not automatically permit editing a colleague’s note, and reading a summary does not automatically permit downloading the entire dataset.

Then define scope: your own jobs, one team, or the whole company. Include record status where relevant. For example, an operator may correct their own draft, while only an owner may reopen an approved record. These rules should be written business decisions rather than a developer’s assumptions while building buttons.

Make the matrix testable

Example scenario	Owner	Operator	Reader
Read jobs assigned to the team	Allowed	Allowed	Allowed
Edit your own draft	Allowed	Allowed	Denied
Edit a colleague’s draft	Allowed	Denied	Denied
Export the company-wide list	Allowed	Denied	Denied
Delete an approved job	Special process	Denied	Denied

The last row reminds us that even an owner need not receive a shortcut for every action. Deletion might require a reason, an archive, or another approval. Define the expected result for each cell: successful, denied, or routed through a special process. Testing then has a clear measure of success.

Test through different entry points

Start with three test accounts and two fictional jobs belonging to different operators. Do not use actual customer data for these examples. Sign in as the first operator, open their own job, and then try the second operator’s job through a direct address provided by the testing team.

Repeat this for save, export and file download actions. If the application has an API, authorized testing needs to cover those requests too. Hidden menus help navigation; permission decisions must be enforced on the server. Checking every request and granting minimum access are principles described in OWASP’s authorization guidance.

Also record what happens after a role changes. An operator moved to another team should not retain access to old jobs simply because a tab remains open. The technical team needs to decide how sessions and permission changes interact, and test that decision in practice.

Add role changes to the scenarios

A static matrix needs a sequence of events resembling real work. In the example application, an operator creates a draft while assigned to team A, then moves to team B. Decide beforehand whether the operator may read team A’s work history, edit an unfinished draft or see only new assignments. There is no single answer for every business; the decision must be known before testing begins.

Use accounts and data prepared specifically for authorized testing. Record permissions before the move, apply the change through the agreed administration feature, then check an already open session and a fresh sign-in. Record when the change happened and the steps taken so the team can repeat the same case. If the result differs from the matrix, report the action and data scope that remain accessible rather than only the role’s name.

Review rules when features are added

A new feature often introduces an action absent from the matrix. For example, copying a job might create a new draft and copy its attachments. Decide whether the user may copy both parts, only selected data, or neither. Also test what happens when the source job is no longer accessible.

When business requirements change, retain the matrix revision and its reason with the test cases. Identify who approves the rule and which team demonstrates the result. Testing can then focus on changed permissions while retaining coverage of existing consequential actions. A matrix that can be updated helps process owners and developers keep their discussions anchored to the same rules.

Keep repeatable evidence

A denial should make sense to the user without exposing records they may not read. Check whether titles, previews, attachments or search results still reveal information even when the detail page is blocked. A test is not complete just because an “access denied” message appears.

Keep a short record of the test account, data scope, action, expected result, actual result and application version. When business rules change, update both the matrix and its test cases. This matrix is a working tool rather than a security certificate.

For a new project, discuss roles and data scope during web app planning. Include an example matrix in your project brief for Creatyf so the estimate covers development and testing for the access flows you actually need.

Official sources

• OWASP: Authorization Cheat Sheet
• OWASP: Testing for Bypassing Authorization Schema