Template
Role and object access matrix
Plan positive and negative permission checks across roles, accounts and objects. Include cross-organisation access rather than testing only valid requests.
Download editable MarkdownHow to use this
Useful for: Developers and testers reviewing authorisation in multi-user or multi-tenant products.
Define the intended access rule before writing test requests. Include the object owner and organisation boundary; a role name alone rarely describes the whole permission decision.
Create isolated test identities for each role and organisation. Use objects belonging to each identity and exercise the same operation with permitted and forbidden callers.
Verify responses and side effects together. A denied response is insufficient if the operation still changes data or exposes information in a background job.
Test the authorised surface only, with written permission and non-production data. Add new endpoints to the matrix as the product grows and keep the expected policy under review.
Scope and limitations: Use only against systems you are authorised to test. This matrix is a focused authorisation worksheet, not a complete security assessment or an exploit guide.
Document preview
# Role and object access matrix ## Agreed policy - Product and authorised test environment: - Policy / requirement reference: - Organisation boundary and object ownership rules: - Accounts, roles and isolated fixtures: - Build, tester and reviewer: ## Expected versus observed | Caller | Object owner | Organisation | Operation | Expected | Observed / evidence | | --- | --- | --- | --- | --- | --- | | Member A | Member A | Same | Read own record | Allow, per policy | | | Member A | Member B | Same | Edit another member's record | Deny, per policy | | | Member A | Member C | Different | Read record | Deny without disclosure | | | Organisation admin | Member A | Same | Invite a member | Allow, per policy | | | Organisation admin | Member C | Different | Invite into other organisation | Deny | | | Signed-out visitor | Member A | Any | Read private record | Deny | | These fictional rows illustrate the structure, not a recommended permission policy for every product. Replace them with your agreed rules. ## Checks for each row - Response status and body match the intended policy. - No forbidden object data appears in the response, error or redirect. - The underlying object is unchanged after a denied write. - Background work and notifications did not perform a forbidden operation. - Audit evidence identifies the caller and operation without exposing secrets. ## Findings and follow-up - Reproduction steps using test identities: - User impact and affected operations: - Evidence link and build identity: - Owner, mitigation and planned retest: - Review after permission or endpoint changes: Include read, create, update and delete operations where applicable. Also check bulk operations and exports if they expose the same objects through a different route. A successful login demonstrates authentication; it does not demonstrate that every object boundary is enforced.
Read alongside this worksheet
- Broken object level authorisation: the API risk no scanner will find for youThe top entry on the OWASP API Security Top 10 returns a perfectly normal 200 to the wrong person. Why tooling cannot see it, and how the testing actually runs.
- What an OWASP-based security assessment covers — and what it does notThe difference between a vulnerability assessment and a penetration test, what a report should contain, and why "we ran a scanner" is not an assessment.