On 11 November 2025 OWASP published the Top 10:2025, and Broken Access Control stayed at number one. The Register's coverage reports it affecting 3.73% of the applications tested, with SSRF now folded into the same category. For a multi-tenant SaaS company, access control is the product promise: customer A must never see customer B's data.
That should shape your first penetration test. Most small teams scope a test by listing hostnames and stopping there. A better scope starts from the question your enterprise customers are really asking, which is whether tenants are isolated, and works backwards to accounts, roles and endpoints.
What's affected
Any SaaS company that is about to buy its first or second penetration test: one customer facing web app, one public API, perhaps an admin console and a few background services. The scope document is what the tester prices against and what the customer's reviewer will read later, so gaps in it become gaps in your evidence.
The PCI Security Standards Council's penetration testing guidance, written for cardholder environments but sensible anywhere, makes four points worth borrowing:
- The scope should be representative of all access points and critical systems.
- Give the tester documentation up front, such as application interface documentation and implementation guides, so they know how functionality should work.
- Test every role. Include roles that have no explicit authorization to sensitive data, to confirm they cannot reach it.
- For multi-tenant applications, authenticated testing should use credentials equivalent to a customer user, to see whether those credentials reach data beyond the customer's own.
How to check if you're exposed
Start by building an honest inventory. You are looking for anything a tester would find in an hour that your scope document does not mention.
# Every route your API declares, from the OpenAPI file
jq -r '.paths | keys[]' openapi.json | sort
# Where do your hostnames point?
for h in app api admin status docs; do
echo "$h.example.com -> $(dig +short $h.example.com | head -1)"
done
# Roles defined in your database or IdP export
cut -d, -f3 users_export.csv | sort | uniq -c
Compare the output to your draft scope. Unlisted routes, forgotten admin hostnames and roles nobody remembers creating are the usual surprises.
What to do now
- List targets by name and purpose. Production or a production-like staging copy, with the exact hostnames. The PCI guidance notes that a separate environment identical to production can reduce disruption, as long as the same controls exist there and this is written into the rules of engagement. Any exploitable issue found there must then be corrected in production.
- Attach the API description. An OpenAPI file or Postman collection saves days of discovery.
- Create the test accounts. At minimum: tenant A admin, tenant A standard user, tenant B admin, tenant B standard user. Add a read only role and a support or staff role if you have them.
- Write down the isolation questions. "Can tenant A read, change or delete tenant B objects by changing an identifier?" "Can a standard user call admin endpoints?" "Do exports, webhooks and file downloads respect tenant boundaries?"
- Name what is out of scope and why. Cloud provider infrastructure, third party SaaS tools and off the shelf software you only configure. The PCI guidance says the scope may include systems you manage, build or use, not the provider's own infrastructure, and that off the shelf web software usually needs a configuration review rather than an application test.
- Decide the knowledge level. Black box, grey box or white box. The PCI guidance defines them by how much information you give the tester. The guidance says white box and grey box assessments yield more accurate and comprehensive results than a pure black box one, which may need more time and money to reach the same depth. Grey box (accounts plus documentation) is a sensible default.
- Agree success criteria. For example: "observe another tenant's data using a standard user account" counts as a critical finding and ends that line of testing.
- Fix the dates and the contact path. Test window, named contacts on both sides, and an emergency stop contact.
Here is a scope document you can adapt. Everything in it is an example value:
Engagement: Annual external application test
Environment: staging.example.com (mirrors production configuration)
In scope:
app.example.com customer web application
api.example.com public REST API, OpenAPI file attached
admin.example.com internal admin console
Out of scope:
cloud provider infrastructure, payment processor pages,
corporate email, employee phishing
Accounts supplied:
tenant-a-admin, tenant-a-user, tenant-b-admin, tenant-b-user, support-staff
Knowledge level: grey box (accounts, API description, architecture diagram)
Priority questions:
1. Tenant isolation across API, exports and file downloads
2. Privilege escalation from standard user to admin
3. Authentication and session handling, including password reset
Test window: Tuesday to Thursday, 09:00 to 17:00 UTC
Stop and call: security@example.com, +1 555 0100 (any outage or sensitive data exposure)
Deliverables: report, retest of high and critical findings within 60 days
How to avoid this trap
- Do not scope by hostname alone. A hostname list says nothing about roles, tenants or business logic.
- Do not give the tester one account and call it multi-tenant testing. Two tenants is the minimum for isolation tests.
- Do not leave out the admin console because it is "internal". Reachable from the internet means in scope.
- Do not forget the retest in the price. Add it to the first quote.
Why it matters
A scope document is also evidence. When a customer reviewer reads your penetration test summary, the first thing they check is what was tested. A report that covers the app and the API with multiple tenants and roles carries real weight. A report that covers one marketing site does not, no matter how clean it is.
Good scoping also keeps the test efficient. Testers bill by time, and time spent discovering undocumented endpoints or waiting for credentials is time not spent on your riskiest logic.
Try it yourself
Write your own version of the scope document above in under thirty minutes. If you cannot fill the "Accounts supplied" line, you have found your first preparation task.
Quick check
What is the minimum account set for testing tenant isolation?
Two tenants, each with at least an admin and a standard user. That lets the tester try cross tenant access and in tenant privilege escalation.
Should the cloud provider's own infrastructure be in scope?
No. The PCI guidance says the scope may include systems you manage, build or use, but not the infrastructure the third party provides. Check the provider's testing policy for what you may test.
Why attach an OpenAPI file?
It tells the tester how the API is supposed to work, so time goes to finding real flaws instead of mapping endpoints.
