OWASP's API Security Top 10 separates broken object, property and function authorization into different risk categories. That distinction matters in procurement. A report that says “authorization tested” can still miss a tenant boundary, a hidden field, an administrative operation or a sensitive business workflow. A buyer needs to know which boundary was exercised and what evidence shows that the expected decision held.
Quick answer. Use a matrix that crosses identities, resources and operations. For each applicable access boundary, ask the tester to show an allowed request, an unauthorized request from another role or tenant, the observed response, business impact and a retest result. Also name any sensitive flow that could be abused through excessive or automated use. The table below is an original buyer-facing synthesis of OWASP API1, API3, API5 and API6. Stingrai can use it to scope a human-led web and API penetration test around your actual roles and transactions.
The matrix is designed for security leaders, product owners and procurement teams buying an assessment, as well as engineering teams reviewing the result. It specifies evidence to ask for, not a universal claim that every row applies to every API. A public catalog endpoint, for example, has a different expected decision from a payroll export. Mark a row not applicable only after the owner identifies the relevant data and access rule.
What the matrix measures
Authorization has more than one axis. API1:2023 concerns whether the caller may act on this object. API3:2023 asks whether that caller may read or alter this property of an otherwise accessible object. API5:2023 concerns access to the function itself. Separately, API6:2023 concerns excessive or automated use of a sensitive business flow, even when individual requests are permitted. We include that as an adjacent business-risk check, not another authorization class.
These categories are a useful taxonomy, but a purchase order needs more detail. We recommend capturing the identity, tenant, resource owner, action, expected result, actual result and evidence reference for each test. That record makes it possible to distinguish a failed control from a tester's assumption about how the product should work. OWASP ASVS 5.0 is a broader verification standard for web applications and services; use it to extend coverage beyond this authorization-focused matrix.
Figure 1: Three authorization checks and one adjacent business-flow abuse check, mapped to evidence a buyer can review. Sources: OWASP API1, API3, API5 and API6.
The API authorization test matrix
Each row is a proposed test objective. The “proof to request” column is what should appear in the workpapers or report, suitably redacted for sensitive records. The source column identifies the underlying risk category, not a claim that OWASP prescribes this exact test case.
Boundary | Buyer-supplied test context | Proof to request | Risk basis |
|---|---|---|---|
Object ownership | Two users with equivalent roles but separate records | Allowed access to the owner's record and a denied result for the peer's record | |
Tenant separation | Two organizations with comparable subscriptions and distinct data | Cross-tenant denial for read, update and export paths, including background jobs | |
Delegated access | An owner, a permitted delegate and a non-delegate | Evidence that the delegate's grant is bounded and the non-delegate is denied | |
Nested resource | Parent and child objects with different owners | Proof that access to a parent does not silently grant access to every child | |
Property read | An object with public and restricted fields | Response examples showing the restricted field absent for the lower role | |
Property write | A mutable record with server-controlled fields | Evidence that a caller cannot change fields outside its permitted set | |
Administrative function | Standard and administrator accounts | Denial of the administrator operation for the standard account | |
Role transition | A user before and after a role change, with the product's revocation policy | Observed access from new and existing sessions, compared with the documented policy and expected timing | |
Bulk operation | A list or export spanning many objects | Results showing filtering is enforced on every returned record | |
Alternate interface | REST, GraphQL, mobile or partner route to the same resource | Comparable authorization decisions across each in-scope interface | |
Sensitive business flow | A purchase, payout or reservation flow with an owner-defined acceptable-use rule | Safe evidence of how the flow handles controlled repetition or automation against the defined limit | |
Third-party callback | Partner or webhook action that changes an internal record | Evidence that the callback identity and target resource are bound to the intended tenant |
The table is deliberately about outcomes. It does not prescribe an exploit recipe or assume a particular API framework. A test may use authenticated accounts, source-assisted review or safe dynamic requests, depending on the rules of engagement. The report should explain which approach was used, because an omitted role or integration can create a false impression of coverage.
Prepare the access model before the vendor starts
The best input to an authorization test is a short access map approved by the product owner. Start with the applications and API hosts in scope. For each, list user classes, tenants, administrative roles, service accounts and partner identities. Then identify the business objects each class should own or access. A tester cannot infer every entitlement from an endpoint list alone.
Create paired accounts. Two accounts in the same role but different tenants test horizontal separation. An administrator and a standard user test function access. An owner and a delegated user test whether sharing was implemented as intended. Include accounts that recently lost access so the tester can inspect the effect of revocation. The point is to supply a clear expected result, not to make the test easier to pass.
Next, identify the workflows that carry real business value: export, billing, approvals, payouts, invitations, account recovery and bulk changes. OWASP API6 treats unrestricted use of sensitive flows as a distinct risk because a permitted endpoint can still enable harmful volume or automation. Tell the vendor which usage limits are contractual, financial or operational, and which controls are intentionally absent. Agree on a safe test volume before exercising those limits; a generic rate-limit finding does not by itself explain the business consequence.
Finally, agree on safe data and stop conditions. Use seeded records and designated test tenants. Confirm which actions may send notifications, create financial effects or contact downstream vendors. Ask for a rules-of-engagement appendix that names those boundaries. NIST's assessment guidance describes penetration testing as a controlled assessment under specific constraints, which is exactly the discipline needed here.
What a strong report lets you verify
A strong authorization finding shows the actor, target, expected decision, observed decision and impact. A screenshot of a response without the test identity and object ownership is hard to interpret. The report should say whether the tester accessed a different customer's record, altered a restricted property, invoked a higher-privilege function or crossed a business rule. It should also say which similar routes were checked and which were outside scope.
For a passed control, ask for representative negative results, not an assertion that “no issues were found.” That does not mean documenting every request. It means retaining enough examples to prove the major boundary classes were exercised. If a finding is fixed during the assessment, the closeout should name the tested version and show a retest of both the originally affected route and the relevant sibling routes. This is the evidence that helps a security leader answer an enterprise customer's follow-up question.
Ask the vendor to deliver a compact coverage table with the same column names as the matrix above. The buyer can then compare the statement of work with the final report without reading every technical appendix. The matrix also makes scope changes visible: if a mobile client or partner API was excluded, mark it as excluded rather than silently treating it as covered.
How to use the matrix in a buying decision
Send the matrix with your request for proposal and ask vendors to mark each applicable row included, optional or excluded. Require an explanation for exclusions. Ask who supplies test accounts, who approves tenant data, whether the team will test authenticated roles, and how a finding becomes a retest result. Price comparisons are more meaningful when each quote covers the same identities and workflows.
For a web application and associated APIs, Stingrai's web application penetration testing service can be scoped around these access checks and sensitive flows. Its human-led engagements can include authenticated testing across roles and report confirmed findings with remediation guidance. Stingrai's pricing page describes packages for one web application and associated APIs; a multi-application program needs an agreed custom quote. This matrix is a practical way to send that scope before a call.
Reuse and citation
This matrix is an original synthesis by Stingrai, reviewed against the primary OWASP categories linked in each row. If it informs your article, buying guide or request for proposal, cite and link to Stingrai, “API Authorization Test Matrix 2026,” 15 October 2026. The linked OWASP documents remain the primary sources for their risk categories.
Frequently Asked Questions
What should an API authorization penetration test cover?
It should cover the object, property, function and tenant authorization boundaries that matter to the product, plus any sensitive flow at risk of excessive or automated use. The buyer should provide paired identities and an expected access map, then require evidence of allowed and denied outcomes in the final report. Stingrai can scope a human-led web and API test around those roles and workflows.
Is a BOLA test enough to assess authorization?
No. BOLA concerns access to an object, while property-level and function-level failures concern different boundaries. A business workflow may also be usable in a harmful way despite technically valid endpoint access. The statement of work should name each applicable class rather than use one broad “authorization” line.
Do I need separate test accounts for each tenant?
Yes, if tenant isolation is in scope. Paired accounts in distinct test tenants let the assessor compare an authorized request with an unauthorized cross-tenant request. Without that pairing, a report may show functional testing but offer little evidence that the tenant boundary held.
Should the report include passed checks as well as findings?
Yes. A short coverage table and representative negative results show which boundaries were actually exercised. They also make exclusions explicit. The report still needs detailed proof and impact for every confirmed finding.
Can automated testing replace a human authorization review?
Automation can repeat known identity and object comparisons, but the buyer must still define the access policy and the business meaning of each workflow. Ask how the vendor validates unexpected behavior, tests role interactions and explains impact. Choose the approach that produces reviewable evidence for your particular application.
Related reading
References
Talk to Stingrai
Send your access map and the rows you need tested to Get a Quote, or book a free discovery call to discuss a human-led API assessment.
