Browse the Knowledge Hub32 resources
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
RequiredStable identifier, prefixed by module.
Test case
RequiredWhat 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
RequiredThe precise observable outcome, including message text where the wording itself is the requirement.
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.
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 improvementMulti 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 servicesMore test case sets
View allTest cases for a login page
Test cases25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.Test cases for a registration form
Test cases28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.Test cases for search functionality
Test cases28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.Test cases for a shopping cart
Test cases27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.Test cases for checkout and payment
Test cases30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.Test cases for file upload
Test cases28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.Test cases for forgot password
Test cases26 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 cases26 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 cases27 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 cases26 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 cases24 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 cases26 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 cases25 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 cases28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.Sources
- OWASP ASVS verification requirements for authentication, session and access control.
- OWASP Top 10 the risk categories these security cases map to.
- OWASP Web Security Testing Guide test procedures for enumeration, injection and authorisation.
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.