View all services
Talk to QA Advisor
Browse the Knowledge Hub32 resources
/Test Cases/User roles and permissions test cases

Test cases

Permission test cases, because these defects are completely silent

Twenty six cases covering vertical and horizontal privilege checks, object level authorisation, tenant boundaries, mass assignment, exports and search leaks, nested resources, mid session role changes, share links and audit trails. Nothing errors when authorisation is wrong. The wrong person simply sees more.

26cases/5coverage types/15security cases/FreeCSV download

All 26 test cases, ready to copy

Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.

Last updated

26 worked examples

PERM-01

Each role can perform its own permitted actions

TypeFunctionalPriorityHigh
Test data
One account per role, exercising the actions that role owns
Expected result
All permitted actions succeed. Build this baseline first, or every negative result below is ambiguous.
PERM-02

A lower role cannot perform a higher role action

TypeSecurityPriorityHigh
Test data
Viewer attempting editor actions, editor attempting administrator actions
Expected result
Refused at the endpoint with a 403, not merely hidden in the interface. Test every action, not a sample.
PERM-03

A user cannot read another user record at the same level

TypeSecurityPriorityHigh
Test data
User A requesting the identifiers of records owned by user B
Expected result
Refused. This is broken object level authorisation, the most common serious API defect and the top entry on the OWASP API list.
PERM-04

A user cannot modify or delete another user record

TypeSecurityPriorityHigh
Test data
Update and delete requests against records belonging to user B
Expected result
Refused. Read protection without write protection is a frequent asymmetry, since the read path was hardened after a review and the write path was missed.
PERM-05

Cross tenant or cross organisation access is refused

TypeSecurityPriorityHigh
Test data
A member of organisation A requesting resources of organisation B
Expected result
Refused, and the tenant boundary is enforced in the query rather than by a filter that a later change could bypass.
PERM-06

Identifiers are not enumerable

TypeSecurityPriorityHigh
Test data
Sequential identifiers walked upward and downward
Expected result
Access is refused regardless of the identifier. Unguessable identifiers are useful defence in depth and are not an authorisation control by themselves.
PERM-07

Hidden interface elements are also blocked server side

TypeSecurityPriorityHigh
Test data
Every button, menu item and route hidden for a role, called directly
Expected result
Every one refused. Interface hiding is presentation, and treating it as security is the single most common authorisation mistake.
PERM-08

Direct navigation to a restricted page is blocked

TypeSecurityPriorityHigh
Test data
Paste an administrator URL into the address bar as a lower role
Expected result
Refused or redirected, with any data loaded by that page also refused. A blocked page that still fires its data request has leaked the data.
PERM-09

Role escalation through the profile or role field is refused

TypeSecurityPriorityHigh
Test data
Send a role or permission field in a profile update request
Expected result
Ignored or rejected. Mass assignment through a permissive update handler is a routine finding.
PERM-10

A role change takes effect for an active session

TypeStatePriorityHigh
Test data
Demote a signed in user, then act from their existing session
Expected result
New rights apply within the documented window, and cached claims in a token do not grant removed permissions until expiry.
PERM-11

Removing a user ends their access

TypeStatePriorityHigh
Test data
Delete or deactivate an account with a live session and an issued API token
Expected result
Sessions are terminated and tokens stop working. A deactivated account whose token keeps working is an offboarding failure.
PERM-12

Removing a user from one organisation preserves the other

TypeStatePriorityHigh
Test data
A user who belongs to two organisations, removed from one
Expected result
Access to the first ends immediately, access to the second is unaffected, and nothing personal is deleted with the membership.
PERM-13

Permission inheritance behaves as documented

TypeFunctionalPriorityHigh
Test data
Nested groups, teams or folders with inherited rights
Expected result
Effective permissions match the documented rule, and the interface can explain why a user has a given right.
PERM-14

Conflicting grants and denials resolve predictably

TypeBoundaryPriorityHigh
Test data
A user granted access through one group and denied through another
Expected result
The documented precedence applies consistently, usually deny wins, and the outcome is the same through every path to that resource.
PERM-15

A user with no roles has no access

TypeBoundaryPriorityHigh
Test data
Account created with no role assigned
Expected result
Denied by default rather than defaulting to the lowest role. Fail closed, and say so in the message.
PERM-16

Custom roles enforce exactly their permission set

TypeFunctionalPriorityHigh
Test data
A custom role with two permissions granted and two adjacent ones withheld
Expected result
Granted actions succeed and withheld ones are refused, including through any bulk or import path.
PERM-17

Bulk actions respect per record permissions

TypeSecurityPriorityHigh
Test data
Select twenty records, five of which the user cannot modify, then act on all
Expected result
The permitted subset succeeds and the rest are refused with a clear report. Bulk endpoints frequently check the role once and then loop.
PERM-18

Exports and reports honour permissions

TypeSecurityPriorityHigh
Test data
Export a list as a restricted role
Expected result
The file contains only permitted records and permitted columns. Exports commonly bypass the filters applied to the screen.
PERM-19

Search and listing endpoints honour permissions

TypeSecurityPriorityHigh
Test data
Search for a term matching a restricted record
Expected result
Absent from results and absent from the result count, since a count alone discloses existence and volume.
PERM-20

Field level restrictions hold in the API response

TypeSecurityPriorityHigh
Test data
A record containing fields a role must not see, such as salary or contact details
Expected result
Restricted fields are absent from the payload, not merely hidden in the rendered view. Inspect the raw response.
PERM-21

Related resources cannot be reached indirectly

TypeSecurityPriorityHigh
Test data
A permitted parent record with an expansion or include parameter pointing at a restricted child
Expected result
Refused or omitted. Nested and expanded resources are where authorisation checks are most often skipped.
PERM-22

Shared links respect their intended scope

TypeSecurityPriorityHigh
Test data
A share link opened by a signed out user, an unintended recipient, and after revocation
Expected result
Access matches the stated scope, revocation is immediate, and a link intended for viewing does not permit editing.
PERM-23

Impersonation or support access is controlled and logged

TypeSecurityPriorityHigh
Test data
A support user impersonating a customer, if the feature exists
Expected result
Permitted only for the intended role, time limited, clearly indicated in the interface, and recorded in an audit trail identifying the real actor.
PERM-24

Privileged actions are recorded in an audit trail

TypeFunctionalPriorityHigh
Test data
Role change, permission change, user removal, export of sensitive data
Expected result
Each entry records who, what, when and from where, and the trail cannot be edited by the people it audits.
PERM-25

Authorisation holds under concurrent requests

TypeStatePriorityMedium
Test data
Revoke a permission while a long running request from that user is in flight
Expected result
The outcome is consistent and explainable, with no partially applied change that leaves data in a state the user was not entitled to create.
PERM-26

Denial messages are clear without being informative to an attacker

TypeAccessibilityPriorityMedium
Test data
Trigger a refusal in each role
Expected result
A message that explains what to do next, such as who to ask for access, announced to assistive technology, and without disclosing whether the resource exists.

What goes in each field

ID

Required

Stable identifier, prefixed by module.

Test case

Required

What is being verified, in one line.

Type

Functional, negative, boundary, security, state, performance, accessibility or compatibility. Use it to check coverage is spread rather than clustered on the happy path.

Priority

Risk based. Every case where a user reaches data or an action outside their role is High, because authorisation defects are silent: nothing errors, the wrong person simply sees more than they should.

Test data

The specific values, including the invalid and boundary ones.

Expected result

Required

The precise observable outcome, including message text where the wording itself is the requirement.

How To Use This

Work it as a matrix, not as a list

Every role against every action and every resource type. Sampling is how the one gap survives.

Two accounts, same level

Take an identifier from user A and request it as user B. This one case finds more real defects than the rest combined.

Call what the interface hides

Every hidden button and route, invoked directly. Hiding is presentation, and it is routinely mistaken for a control.

Check exports and search

Both frequently bypass the filters applied to the screen, and both hand over volume as well as content.

Demote a live session

Change a role while the user is signed in. Cached token claims often keep permissions that were revoked.

What Most Sets Miss

Where authorisation actually fails

Horizontal access is the gap that matters most and gets tested least. Teams check that a viewer cannot do administrator things, which is vertical, and forget that one customer reaching another customer record is the same severity and far more likely. Authenticate as one user, capture a resource identifier, request it as another, and repeat for update and delete rather than only for read.

Write paths lag read paths. A review hardens the endpoints that return data, and the update, delete, bulk and import paths keep their original permissive checks. Always test all four verbs against a resource you should not own.

Exports, search and nested resources are the three routes that bypass otherwise correct authorisation. An export builds its own query, a search index is filtered after retrieval, and an expansion parameter pulls a child record whose own permission check was never written. All three produce leaks that look impossible from the screen.

Mid session role changes are the state case worth writing down. When permissions live in a token, revoking a role does nothing until that token expires, so a demoted or dismissed user keeps working access for the remainder of its lifetime. Decide the window deliberately, document it, and test that it holds.

Suggest an improvement

Multi tenant or role heavy product?

QAble tests authorisation as a matrix at the API layer, which is where permission defects live and where interface testing cannot reach them.

Security testing services

More test case sets

View all

Test cases for a login page

Test cases
25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.

Test cases for a registration form

Test cases
28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.

Test cases for search functionality

Test cases
28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.

Test cases for a shopping cart

Test cases
27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.

Test cases for checkout and payment

Test cases
30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.

Test cases for file upload

Test cases
28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.

Test cases for forgot password

Test cases
26 cases on reset token expiry, single use enforcement, session invalidation and the enumeration and rate limit gaps that are routine here.

Test cases for OTP verification

Test cases
26 cases on expiry, resend throttling, attempt limits, code reuse, delivery failure and the brute force window teams forget to close.

Test cases for form validation

Test cases
27 rules-based cases on required fields, length and numeric boundaries, client and server parity, hidden field tampering and error accessibility.

Test cases for a date picker

Test cases
26 cases on timezone shifts, ambiguous day and month order, impossible dates, min and max limits, leap years and keyboard operation.

Test cases for pagination

Test cases
24 cases on ordering stability, records changing mid-session, page size caps, deep offset cost, permission-filtered totals and state restore.

Test cases for push notifications

Test cases
26 cases on app states, deep link routing, token release on sign out, lock screen privacy, preferences, provider failures and platform differences.

Test cases for reports and data export

Test cases
25 cases on permission filtering in the file, spreadsheet formula injection, encoding, typed numbers and dates, row limits and audit logging.

Test cases for a chatbot

Test cases
28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.

Sources

Want permissions proven across every role?

QAble builds authorisation coverage that runs in your pipeline, with ISTQB-certified engineers. Start with a free QA audit.

Talk to QA Advisor