API permission testing asks whether the service enforces the product's rules at every meaningful boundary. A valid session should not grant access to every customer record, and permission to read an object should not automatically permit editing it. The most useful starting point is a small, controlled exercise with known accounts and known data. This checklist is designed for an API you own or have explicit authorization to assess, using a test environment and resources prepared for that purpose.
Define the allowed exercise
Write down the environment, endpoints, test identities, permitted actions, request limits, and stopping conditions before sending requests. Identify the person who can resolve an unexpected result. For state-changing checks, use disposable records and a documented cleanup process. The scope should be concrete enough that a second tester can repeat the work without guessing which systems or accounts are included.
Prefer ordinary application requests that exercise known business rules. This permission review does not need uncontrolled scanning or attempts to discover unrelated customer identifiers. If a response unexpectedly exposes real customer information, stop that case, preserve only the minimum evidence needed, and follow the agreed reporting process. A controlled exercise should produce a clear engineering decision without broadening the exposure.
Turn product rules into an access matrix
Choose one resource, such as an expense report in a fictional internal application. List the relevant actors: report owner, teammate, manager, administrator, and anonymous visitor. List the actions separately: read, edit, approve, export, and delete. Ask the product owner to state which combinations are allowed. A manager might approve a submitted report while being unable to change the original receipt.
Capture contextual conditions as well. Perhaps owners may edit drafts but cannot change approved reports. Perhaps managers may access only reports from their current team. These conditions belong beside the role definition. A role name alone often hides the rules that matter most to the business.
The OWASP guidance on broken object-level authorization emphasizes checking the caller's permission for the requested action on the requested object. Authentication and an unpredictable identifier do not replace that check. Use this principle as the foundation for your matrix, then extend it with your application's specific workflow.
Prepare known identities and owned fixtures
Create two test organizations with different records and at least one ordinary user in each. Give every fixture an unmistakable label, such as Team Amber draft and Team Violet draft. Keep a small inventory of their identifiers, owners, current states, and intended permissions. Do not derive test identifiers from real customer activity when purpose-built fixtures can provide the same evidence.
First confirm that each intended owner can perform the allowed action. This positive control matters: a denied cross-account request is less informative if the endpoint is broken for everyone. Next, repeat the same kind of request using the other controlled identity and the known fixture. Compare the result with the matrix. The Security Test Explore API guide organizes this work around clear authorization boundaries.
Check actions independently
Test read, update, delete, export, and business-specific actions as separate cases. They may pass through different application code and different policy checks. If the product exposes both a normal detail route and an export route, both need an explicit decision about who may access the resource. Coverage of one route is evidence about that route, not proof about every representation of the same data.
- For an allowed read, confirm that the correct object is returned and the expected visible fields are present.
- For a denied read, confirm that the response follows the agreed error contract and does not contain the protected content.
- For an allowed update, verify the saved state through an independent read or database check in the controlled environment.
- For a denied update or deletion, verify that the original state remains intact.
Choose whether denied access returns a forbidden response or conceals object existence according to the application's policy. Consistency and information exposure matter more than imposing one response code on every product. Document the expected outcome so future tests do not treat different legitimate policies as interchangeable.
Review the fields inside a permitted object
Permission to see a record does not necessarily mean permission to see every property. For the expense example, an employee may need the amount and approval status while an internal reviewer alone can see an investigation note. Prepare a response-field policy for sensitive properties and check it using each controlled role.
Review writable properties separately from readable ones. A client may submit an ordinary description while fields such as organization ownership or approval status must be controlled by the server or a specific workflow. In the test environment, submit only the prepared cases from your policy and verify that unauthorized property changes are rejected or ignored as documented. Inspect the stored record afterward so a misleading response does not hide a change.
Test permission changes over time
Authorization is a lifecycle, not a single login event. A teammate may move to another organization, a manager may lose approval authority, or a shared report may become private. Create a case that grants access, verifies it, changes the permission, and checks access again using the intended session behavior. Record how quickly the product promises the new policy will apply.
Review caches and background jobs in that context. A cached response must not be served to the wrong identity, and a queued export may need a defined permission check when it runs. Decide whether access is evaluated at request time, execution time, delivery time, or several points. The appropriate rule depends on the workflow; the test should make that choice visible.
Include collections and alternate representations
A protected detail endpoint can coexist with a list endpoint that reveals the same records. Check list results, filtered collections, counts, downloads, and nested resources that the application deliberately exposes. Use a fixture set small enough to know exactly which items should be visible. This makes an extra record a clear failure rather than an ambiguous response to a broad query.
Consider partial disclosure too. A forbidden record's title, owner name, or total amount may be sensitive even when its full body is hidden. Define which metadata may be visible and test that policy explicitly. Keep the exercise focused on documented routes and approved fixtures instead of expanding into unknown systems.
Capture evidence that a developer can act on
For each finding, record the rule, test identity, resource label, action, expected result, actual result, and environment version. Include a minimal redacted request and response only when they clarify the behavior. A concise reproduction is more useful than an unfiltered traffic archive. Avoid retaining tokens, session cookies, or unrelated personal data in tickets.
Describe the impact through the demonstrated permission failure. For example, the evidence may establish that one ordinary test user can export the other test organization's report. Do not claim access to every customer or a complete compromise without evidence. Give the engineering owner enough information to trace the policy path and reproduce the same controlled case.
Convert confirmed rules into regression checks
After fixing a permission defect, preserve both the allowed and denied cases. A fix that denies everyone may remove the immediate exposure while breaking the product. Run the focused checks when authorization code, resource queries, or workflow transitions change. The Django API QA guide shows how response and state assertions can support this approach within a framework.
Keep permission testing distinct from a claim that the entire API is secure. It provides evidence about tested identities, resources, actions, and conditions. Other concerns, including availability, dependency safety, and input handling, need their own review. For broader planning, use the authorized API assessment guide to define complementary work without overstating this checklist's coverage.
Conclusion: make access rules observable
Effective API permission testing begins with rules people can agree on and fixtures whose ownership is known. Check actions, fields, lifecycle changes, and alternate representations, then verify the response and the resulting state. Preserve concise evidence and automate confirmed expectations. This turns authorization from an assumption in application code into behavior the team can inspect before a release.
