A SaaS founder emailed me a good question before buying anything. Do you test authenticated tenant workflows, tenant isolation, and business logic?
For our $495 test, the answer is no. That test looks at your app from the outside, without a login. It's useful, but it can't tell you whether one customer can see another customer's data. If you sell software to companies, that's the question your buyers care about most.
Why this is its own kind of test
In a multi-tenant app, all your customers share the same code and usually the same database. The only thing keeping them apart is your authorization logic, and that logic lives behind the login. A scanner that can't sign in never reaches it.
These bugs are also easy to write. A new endpoint takes a record ID and forgets to check who's asking. OWASP ranks this first on its API Security Top 10. The attack is as simple as changing the ID in a request.
What the test should cover
Tenant isolation. From inside one tenant, try to read or change another tenant's data. Do it through the UI, then go straight at the API, because the UI usually hides what the API still allows. OWASP's multi-tenant cheat sheet has a good rule here: treat a tenant ID sent by the client as a selector only, and check it against the user's verified membership.
Role boundaries. Read-only users can't write. Regular members can't reach admin functions like team access, security settings, or integrations. And check this one specifically: someone who belongs to two tenants can't carry their admin rights from one into the other, where they're only a member.
Public sharing. Lots of SaaS apps let you share a report, form, or post with a public link. The test should confirm that link shows only what it's meant to, and that nobody can use it as a way into the private data around it.
Business logic. This covers the flaws no scanner understands, because the requests all look normal. Start with whatever touches money, outside systems, or customer communications: payments, integrations, inboxes.
What your tester will need
- Two test tenants, because you can't test isolation with one.
- Accounts for each role in both tenants.
- A staging environment if you have one, with fake data.
- A way to handle MFA on the test accounts.
- A short description of your model. What counts as a tenant? What can each role do? What's meant to be public?
That last one saves the most time, and a few paragraphs is enough. You also want to have it written down for your own team, because your answer is what the tester will hold your app to.
When your customers ask
If a prospect sends you a security questionnaire, an external test alone won't answer a question about customer data separation. A report that says two tenants were tested, and whether one could reach the other, will. And if it finds a hole, fix it first. This is the kind of finding that goes to the top of the list.
We test this as part of our authenticated pen test, with a cross-tenant module and one retest included. It's hands-on work, so it takes more time than the 24-hour external test. If you aren't sure which one you need, ask before you buy. That founder had it right.