OWASP's API guidance says each endpoint that acts on a client-supplied object identifier should check whether the current user may perform that action on that object. In a shared SaaS platform, that decision also depends on the customer's tenant, the user's role, the object's owner, and the workflow state. A procurement brief that says only “test the API” leaves those decisions undefined.
Quick answer. Scope a multi-tenant SaaS penetration test around customer-to-customer isolation, role separation, sensitive fields, and privileged business actions. Supply controlled accounts and data in distinct tenants, then ask for an endpoint and workflow coverage matrix, validated findings, and retest evidence. Stingrai's web application testing explicitly covers tenant boundaries, object and function authorization across role pairs, and the APIs behind the application.
This is a buying and delivery guide, rather than another explanation of how BOLA works. Our BOLA and IDOR explainer examines the vulnerability class itself. Here, the question is what an enterprise security lead should put in a statement of work so that a provider can prove the isolation model holds across the actual product.
Define the boundary the test must protect
“Multi-tenant” is an architecture label, not a test case. A tenant may be an organization, workspace, subsidiary, project, healthcare customer, or reseller account. Some users belong to several tenants. Others have a global support role that can enter a customer's context. The buyer must describe these relationships and the intended access decisions before testing begins. Otherwise a tester may see a successful cross-tenant response without knowing whether it is a defect, an approved shared workflow, or test data configured incorrectly.
Start with the product's own authorization model. Identify the objects that carry tenant ownership: documents, invoices, reports, users, API keys, exports, files, messages, and background jobs are common examples. Mark where an object can move between tenants, where a user can be invited into another tenant, and where an administrator can grant access. For each relationship, write the expected allow or deny result. The goal is a concise entitlement map that the testing team and product owner can both sign off.
Do not use an HTTP status code alone as the acceptance criterion. A denied read may still reveal a filename, count, timestamp, search hit, or notification. A rejected write may still enqueue a job or update a secondary system. OWASP API3:2023 treats sensitive properties in both responses and updates as an authorization concern. The scope should therefore include the returned representation and downstream effect, not just the primary response.
Give the testers a usable account and data model
A practical test needs more than a single administrator account. Provide accounts in separate customer tenants, plus the roles that determine whether a user may view, edit, approve, export, or administer an object. If the product has support impersonation, reseller administration, or shared workspaces, include those paths as their own trust boundaries. A customer A administrator and a customer B administrator are not interchangeable; their equal role does not imply access to the same records.
Use synthetic records that look realistic enough to exercise filters, attachments, bulk operations, and workflow states. Record which account owns each fixture. For sensitive production systems, agree on non-destructive test windows, allowed operations, rate limits, and cleanup. These are scoping decisions for the buyer and provider, not a substitute for authorization tests. The OWASP API1:2023 control is about an action on a particular object; without known owners, a test cannot convincingly show whether that control worked.
Ask the vendor to note any area where the intended access rule remains unknown. “Not tested because no second tenant was provided” is materially different from “cross-tenant access was tested and denied.” The final report should make that difference visible to procurement, engineering, and the customer auditor.
Figure 1: A buyer's authorization scope matrix derived from OWASP's object, property and function categories. Sources: OWASP API1, API3 and API5.
Put object, property and function checks in the statement of work
The scope should name the boundaries, not merely cite “OWASP Top 10.” OWASP API1:2023 addresses access to another person's object. OWASP API3:2023 addresses fields a caller should neither read nor change. OWASP API5:2023 addresses functions reserved for a different role or group. A multi-tenant platform can fail any one of these independently.
Boundary to verify | Buyer-provided fixture | Evidence to request |
|---|---|---|
Object ownership | Two tenants with distinct records of the same type | A permitted baseline and a denied cross-tenant action for each relevant object and verb |
Property visibility and edit rights | Records with customer-only, support-only and admin-only fields | Redacted responses and rejected or ignored unauthorized field changes |
Function and role rights | Standard, tenant-admin and support accounts | Allowed and denied results for approval, export, invite and administrative actions |
Membership changes | Invited, suspended, removed and multi-tenant users | Results before and after role or membership transitions |
Indirect access | Search, reporting, attachments, webhooks and queued jobs | Evidence that secondary paths enforce the same entitlement policy |
This table is a scope worksheet, not a list of confirmed defects. For each row, the buyer should specify the product's expected result. A shared document, delegated approval, or support escalation may be legitimate if policy permits it. The test must ask whether the policy is enforced consistently at every path to the same resource.
Include the paths outside the main screen
The most important boundary may sit behind a feature that procurement does not call an API. Search indexes, export jobs, report generation, notifications, file download links, webhooks, GraphQL resolvers, mobile backends, and administrative consoles can all expose tenant-owned objects. The test inventory should map user-facing workflows to the services and endpoints they call. It should cover read and write behavior, because protecting the detail page does not prove that an update, deletion, or bulk action is protected.
Include changes over time. A user can be invited, promoted, suspended, removed, or moved between workspaces. An already-issued session or queued job may still carry a previous entitlement. The statement of work should ask the provider to check these transitions with controlled accounts. This makes the result useful to an enterprise customer asking what happens after an employee leaves or a support grant ends.
Use OWASP ASVS 5.0.0 as a requirement vocabulary if the purchasing team wants a reusable control map. A map to a standard is most useful when the report identifies the product behavior and evidence behind each mapped requirement. A simple “ASVS tested” badge does not tell engineering which role pair, object, or workflow was actually covered.
Ask for deliverables that survive procurement review
The report should identify the tested build or environment, dates, accounts and roles, endpoints or workflows in scope, exclusions, and the agreed rules of engagement. It should separate observed results from assumptions about product policy. Each finding needs the affected tenant boundary, the expected outcome, the observed outcome, a redacted request and response or equivalent workflow evidence, business impact, and a specific remediation recommendation. Sensitive customer data should be removed from shared copies.
A coverage appendix is as valuable as the findings list. Ask for a matrix that shows each object type against roles and tenants, including a permitted control case and the negative case. Where a path is out of scope because of missing access, list the gap. Where an attempted action was blocked, explain the evidence. A clean report with no coverage detail is difficult for a buyer to distinguish from a shallow test.
Request a retest record tied to the original findings. The record should say which build was retested, whether the original action is now denied, and whether adjacent paths still behave correctly. For recurring releases, preserve the same fixture model so the next assessment can compare like with like. Choose between a one-time or annual assessment and a continuous testing program according to release cadence and customer commitments.
Questions to put in an RFP
Which tenant pairs, roles, support privileges, and cross-organization sharing features will you test?
Will you test object ownership, sensitive properties, and privileged functions as separate control families?
How will you discover the APIs behind search, export, attachments, integrations, and asynchronous jobs?
What access and synthetic data do you require before the clock starts?
How will the report distinguish a product-authorized share from a cross-tenant defect?
Will you provide a role-by-object coverage matrix and redacted request-level evidence?
What is the retest process, and what evidence will be updated after a fix?
An answer that names only scanner coverage does not settle these questions. The provider needs to demonstrate how the test will establish the expected entitlement for each account and object. That is the practical difference between a vulnerability scan and a defensible multi-tenant assessment.
Where Stingrai fits
Stingrai is a CREST-accredited offensive security company whose web application and API service expressly includes authenticated roles, object and function authorization, tenant boundaries, and business logic. Its service page says findings are validated with request and response evidence. For a SaaS buyer, the useful starting brief is the tenant and role matrix above, together with the application's own rules for invitations, support access and data sharing.
For a broader estate, ask for a custom scope that names the applications and integrations separately. The test should follow the real customer boundary, even when that boundary crosses several components. Stingrai's testing can support a compliance program and produce evidence for an audit, while the report remains focused on observed security behavior.
Frequently Asked Questions
What should a multi-tenant SaaS penetration test include?
It should include cross-tenant object access, role and function boundaries, sensitive properties, membership changes, and indirect paths such as exports and attachments. The buyer should supply controlled accounts in distinct tenants and require a coverage matrix with evidence for allowed and denied actions.
Is a BOLA test the same as a tenant-isolation test?
No. BOLA tests whether a caller may act on a particular object. A tenant-isolation assessment uses that check across the product's customer boundary and also examines fields, privileged functions, sharing rules, background jobs and changes to membership.
Can a scanner verify tenant isolation on its own?
A scanner can help enumerate endpoints, but a meaningful result needs known object owners, tenant memberships and expected access rules. Without those fixtures, a successful response may look valid even when it belongs to another customer.
What evidence should an enterprise customer request?
Request the tested environment and build, role and tenant fixtures, a workflow coverage matrix, redacted finding evidence, exclusions, remediation guidance and a retest record. The report should distinguish an observed denial from a path that was never tested.
How often should the scope be repeated?
Repeat the relevant boundary checks when authorization rules, tenant models, integrations or major workflows change. A one-time or annual assessment can establish a baseline; a continuous program can revisit the same fixtures as the product evolves.
Related reading
References
Talk to Stingrai
Share your tenant and role model with Stingrai through Get a Quote, or book a free discovery call to define the application and API boundary before testing.
