How to Test Error States in Web Applications: A Practical QA Guide

RBAC Testing: Why Hiding a Button Doesn't Mean Your Application Is Secure

A user logs into an application successfully.

The dashboard opens.

The navigation looks correct.

Some buttons are visible while others aren't.

The QA test passes.

But there is still an important question:

Can this user access something they aren't supposed to access?

That's the real problem behind Role-Based Access Control (RBAC) testing.

Modern applications rarely have only one type of user. They may have administrators, managers, employees, customers, support agents, editors, viewers and many other roles.

Each role can have different permissions.

Testing those permissions isn't simply about checking whether the correct buttons appear.

The actual authorization boundary often exists behind the UI.

Authentication vs Authorization

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

A successful login proves authentication.

It doesn't prove authorization.

For example, a Manager may be able to log in successfully but shouldn't necessarily be able to delete users.

A QA strategy therefore needs to test both permitted and restricted actions.

Start With a Permission Matrix

Before creating detailed test cases, define what each role can actually do.

For example:

| Action | Admin | Manager | Employee | Viewer |
|---|---|---|---|---|
| View dashboard | Yes | Yes | Yes | Yes |
| Create record | Yes | Yes | Yes | No |
| Edit record | Yes | Yes | Own only | No |
| Delete record | Yes | No | No | No |
| Export data | Yes | Yes | No | No |
| Manage users | Yes | No | No | No |

The actual permissions depend on the application.

The important thing is that the expected behavior is explicit.

A permission matrix gives QA a clear map of what needs to be tested.

Test Both Allowed and Denied Actions

Testing only successful operations is not enough.

For example:

Admin → Delete User → Allowed

Manager → Delete User → Denied

Employee → Delete User → Denied

Viewer → Delete User → Denied

A secure application needs both sides of the test.

It must allow legitimate actions and prevent unauthorized ones.

Don't Stop at the UI

This is one of the most important RBAC testing principles.

Suppose the Delete button isn't visible to a Manager.

That looks correct.

But what happens if the Manager accesses the underlying API directly?

Or opens the protected URL manually?

If the operation succeeds, hiding the button wasn't sufficient.

The UI controls what users see.

The backend must enforce what users are actually allowed to do.

Therefore:

Hidden button ≠ authorization

Disabled button ≠ authorization

Test Direct URL Access

Imagine administrators can access:

`/admin/users`

A Manager doesn't see the link.

Now paste the URL directly into the browser while logged in as a Manager.

The expected result should be an access-denied response or the application's defined restricted state.

If the administrative page opens normally, there is an authorization problem.

Direct URL testing is simple and should be part of RBAC coverage.

Test APIs Independently

Modern applications rely heavily on APIs.

The frontend might correctly hide an administrative function while the API remains accessible.

For example:

`DELETE /api/users/123`

A Manager shouldn't be able to execute this operation if their role doesn't have the required permission.

Test the endpoint using the appropriate user context.

The goal is to verify that authorization is enforced at the backend.

This is particularly important because API access doesn't require the user to follow the application's normal navigation.

Test Resource Ownership

Role permissions aren't always enough.

A user may have permission to view orders, but that doesn't necessarily mean they can view every order.

Consider:

Customer A → Order 1001

Customer B → Order 1002

Customer A should normally be able to access Order 1001.

They shouldn't automatically gain access to Order 1002.

This creates another important testing question:

Does the user have access to this specific resource?

This is different from simply asking whether the user is logged in.

Test Horizontal Access

Horizontal authorization testing checks whether users with similar privileges can access each other's information.

Examples include:

- Employee A accessing Employee B's profile
- Customer A accessing Customer B's order
- Support Agent A accessing another agent's restricted ticket
- User A accessing User B's uploaded document

The users may have the same role.

The problem is unauthorized access to another user's resource.

Test Vertical Access

Vertical authorization testing involves different privilege levels.

Examples:

- Viewer → Edit report
- Employee → Approve request
- Manager → Manage users
- Customer → Access administration functionality

The goal is to make sure lower-privileged roles cannot perform higher-privileged operations.

Both horizontal and vertical access should be included in a serious authorization strategy.

Test Role Changes

Roles can change during a user's account lifecycle.

An Employee may become a Manager.

A Manager may later become an Employee.

These changes create important test cases.

For example:

1. User logs in as Manager.
2. Administrator changes the user's role to Employee.
3. Existing session remains active.
4. User attempts a Manager-only action.

The expected behavior should be defined by the application's session and authorization model.

The important point is that role changes need testing too.

Test Session Expiration

Authorization testing should include session-related scenarios.

Test:

- Logout
- Session timeout
- Token expiration
- Browser refresh
- Multiple tabs
- Previously opened protected URLs

For example, a user accesses a protected page and then their session expires.

After refreshing the page, the protected information shouldn't remain accessible simply because it was previously loaded.

Test Search and Exports

Search functionality can accidentally expose data that the main interface protects.

For example:

A customer searches for another customer's order number.

Can the restricted record appear?

Similarly, a user might be able to view limited data but export a much larger dataset.

Test:

- Search results
- Autocomplete
- CSV exports
- Excel exports
- PDF reports
- Download links

Authorization should apply consistently across these paths.

Test File Access

Files are another important authorization boundary.

Suppose User A uploads a private document.

User B shouldn't be able to access it simply by knowing the file URL or identifier.

Test access through:

- Normal UI
- Direct download URL
- API
- Search
- Old links
- Shared links where applicable

A file hidden from the UI can still represent a security problem if the underlying resource is accessible.

Multi-Tenant Applications Need Extra Testing

Applications serving multiple organizations have another authorization boundary.

Imagine:

Organization A

Organization B

A user from Organization A shouldn't automatically be able to access Organization B's records.

Test:

- APIs
- URLs
- Search
- Reports
- Files
- Exports
- Resource identifiers

Tenant isolation should be treated as a separate testing concern.

Automate the Permission Matrix

RBAC is well suited to data-driven automation.

Instead of writing a completely separate test for every combination, define expected permissions as test data.

For example:

Role:

Manager

Action:

Delete User

Expected:

Denied

Another case:

Role:

Admin

Action:

Delete User

Expected:

Allowed

The same automation framework can then execute many combinations.

This also makes permission changes easier to detect.

UI Tests and API Tests Have Different Jobs

UI automation should verify the user experience:

- Correct navigation
- Correct controls
- Role-specific workflows
- Access-denied states

API automation should verify the actual authorization boundary:

- Protected endpoints
- Unauthorized requests
- Resource ownership
- Response data
- Permission enforcement

Using both provides stronger coverage than relying on either layer alone.

Where AI Can Help

AI can be useful during RBAC test design.

Give it:

- Roles
- Permissions
- Resources
- Requirements

Then ask it to identify missing scenarios.

It can suggest cases involving:

- Direct URL access
- Direct API access
- Resource ownership
- Role changes
- Expired sessions
- Search
- Exports
- Multiple roles
- Tenant boundaries

This can help QA engineers discover gaps in a large permission model.

But AI shouldn't invent the application's authorization rules.

If the requirement says:

"Managers can approve requests."

AI shouldn't assume:

"Managers can delete requests."

AI can ask whether deletion should be allowed.

The product and security requirements determine the answer.

A Practical RBAC Testing Workflow

A QA team can use this process:

1. Document the roles.

Identify every user role.

2. Document permissions.

Define what each role can do.

3. Create a permission matrix.

Map roles to actions.

4. Identify protected resources.

Include pages, APIs, files, reports and data.

5. Test allowed actions.

Verify legitimate access.

6. Test denied actions.

Verify restricted access.

7. Test direct access.

Try protected URLs and APIs.

8. Test ownership.

Verify that users cannot access other users' resources.

9. Test session changes.

Include logout, expiration and role changes.

10. Automate important scenarios.

Put critical authorization checks into the appropriate test suites.

Common RBAC Testing Mistakes

Only testing the UI

A hidden button doesn't prove that the backend is protected.

Testing only positive scenarios

You also need to verify what users cannot do.

Ignoring resource ownership

Role permissions don't automatically define access to every resource.

Ignoring APIs

The API is often the actual enforcement point.

Ignoring direct URLs

Users can navigate directly without using the application's menus.

Ignoring role changes

Existing sessions can behave differently after permission changes.

Ignoring exports and downloads

Sensitive information can escape through secondary functionality.

Assuming login means access

Being authenticated doesn't mean being authorized.

Final Thoughts

RBAC testing isn't simply about checking whether each user sees the correct menu.

A stronger strategy follows the permission boundary through the application.

Ask:

Who is the user?

What action are they performing?

Which resource are they accessing?

Are they allowed to perform that action on that resource?

Can they bypass the UI?

What happens when their role changes?

What happens when their session expires?

These questions produce much stronger authorization coverage.

The most important principle is simple:

Hiding functionality isn't the same as protecting functionality.

A hidden button controls the interface.

Authorization controls access.

AI can help QA teams organize complex permission matrices and identify missing scenarios.

Automation can repeatedly verify those boundaries.

But the expected permission model must still come from the application's requirements.

The goal isn't to create thousands of permission tests.

The goal is to make sure important access boundaries are actually enforced.

Because authentication tells you who someone is.

Authorization determines what they're allowed to do.

And a login test can prove the first without proving the second.