Penetration testing for SaaS companies
A SaaS product is judged on one question above all: can one customer ever see or change another customer's data? BERRY9 engineers test tenant isolation, sign-in and single sign-on, the API, webhooks and the cloud account behind your product, then write the report your enterprise buyers and auditors ask for.
- Typical duration
- 5 to 10 working days
- Testing
- Manual, by engineers
- Report
- Executive + engineering
- Delivery
- Remote, on-site by arrangement
Last reviewed
01 / Where attackers look
What attackers go after in a SaaS product
A SaaS company holds many customers' data behind one application, so one flaw can reach all of them. These are the six areas where we spend the most time.
Tenant isolation
Every request belongs to a tenant. Testers change identifiers, tokens and subdomains to see whether the server checks which tenant owns each record, on every endpoint, every export and every background job.
Sign-in, SSO and SCIM
Password reset, invitation and sign-up flows, single sign-on settings that trust the wrong claim, and user provisioning endpoints that let one customer create users in another's directory.
Roles and admin consoles
The gap between a customer's administrator and your own support staff: impersonation features, internal consoles reachable from the product, and functions that only the interface hides.
API keys and integrations
Keys that never expire, tokens that carry more scope than the customer chose, and public APIs that return full records to callers who should see a few fields.
Webhooks and imports
Features that fetch a URL or read a file for the customer can be turned toward your internal network. Outgoing webhooks need signatures and replay protection, and incoming ones need to be verified.
Cloud and delivery pipeline
Public storage, over-broad roles, secrets in repositories and build logs, and the pipeline that can change production without a second pair of eyes.
02 / Scope
What a SaaS penetration test covers
Most SaaS engagements pair the web application and the API with a review of the cloud account and the delivery pipeline.
| Area | What we check | Service |
|---|---|---|
| Multi-tenant application | Authorization on every object and function, tenant boundaries, roles, business-logic flaws and session handling | Web application testing |
| Public and internal APIs | Object-level and function-level authorization, mass assignment, rate limits, token handling and excessive data in responses | API security testing |
| Mobile and desktop clients | Data stored on the device, traffic interception, embedded keys and the API calls the client makes | Mobile app testing |
| Cloud account | Storage, identities and permissions, network exposure, secrets and logging for the account that runs the product | Cloud security assessment |
| Source and pipeline | Authentication and authorization code, dependency risk, secrets in code and weaknesses in the build and release path | Source code review and DevSecOps services |
| Company network | Office and remote access, the identity system that staff sign in to and the paths from one laptop to production | Network penetration testing and Active Directory testing |
03 / Common flaws
Flaws that recur in multi-tenant products
A handful of mistakes recur in very different products, and a tester can try each one on purpose.
Show details for Flaws that recur in multi-tenant products
Multi-tenant products fail in a few recurring ways, and a tester who has seen them looks for each one deliberately. None of them shows up in a scan, because each one depends on knowing which record should belong to whom.
- Identifiers that can be guessed or listed. A sequential invoice number, or a project identifier visible in a shared link, becomes a way to open other customers' records when the server does not compare the record's owner with the caller.
- A tenant taken from the request. If the tenant is read from a header, a subdomain or a body field that the client controls, changing that value changes whose data is returned.
- Exports, reports and background jobs. The main screen checks the tenant, while the CSV export, the scheduled report or the search index built overnight does not.
- Shared infrastructure. Caches keyed without the tenant, file storage paths that can be altered, and search indexes that mix customers' documents.
- Invitation and sharing flows. An invitation that can be redeemed by any email address, or a share link that never expires and reaches further than the customer expected.
- Support and impersonation tools. Powerful by design, and often protected only by a hidden address.
Our articles on IDOR and business-logic flaws and on the API testing checklist explain how these are found, and our guide to black, gray and white box testing explains why a SaaS test is usually gray box: with accounts in two tenants and each role, the tester spends the days on these questions and not on finding the login page.
04 / Customers and audits
Enterprise customers, SOC 2 and ISO 27001
A penetration test is often the first thing a larger customer asks a SaaS vendor for, and the report is the answer.
Show details for Enterprise customers, SOC 2 and ISO 27001
For many SaaS companies the test is first asked for by a customer. An enterprise buyer's security questionnaire asks when you last had an independent penetration test, what it covered, and whether serious findings were fixed. Our article on what to send when a customer asks lists the options from a short summary to the full report under an NDA.
SOC 2 does not require a penetration test. Its criteria ask for controls that find and manage vulnerabilities, penetration testing is one common way to show that, and your auditor decides what evidence is enough. ISO 27001 works similarly: auditors want to see an ongoing, risk-driven program and proof that findings were acted on. The SOC 2 testing page explains how a test report fits into that evidence. For a SaaS buyer we write two documents from one set of findings: an executive report built to be passed to customers and auditors, and an engineering report for your developers. A retest then shows which findings are closed.
If you are early, read a startup's first penetration test; if you are planning the year, how often to test gives a simple schedule tied to your release cadence.
05 / How it runs
How a SaaS engagement runs
Plan for 5 to 10 working days of testing and reporting; your proposal sets the dates.
Show details for How a SaaS engagement runs
Before day 1
Scoping call
We settle which product areas, roles and environments are in scope and which systems are off limits, and put the result in the proposal.
Day 1
Tenants and access
You set up test tenants with an account for each role and share API documentation. We confirm that access works and tell you the fixed addresses that our traffic uses.
Days 2 to 7
Hands-on testing
Engineers go through tenant boundaries, roles, flows and the API by hand, using tools for breadth, and flag anything urgent the moment it is confirmed.
OutputFindings with proof, as they are confirmed
Days 8 to 9
Reporting
You receive an executive report and an engineering report, then a call in which we explain each finding and the order in which to fix them.
OutputTwo reports from one set of findings
After your fixes
Retest
Each fixed finding is tested again and marked closed, or kept open with the reason.
06 / Preparation
What to prepare before the test
Good preparation puts the time into testing instead of waiting for access.
Show details for What to prepare before the test
- Two test tenants, with one account for each role, and sample data that is not real customer data.
- A staging environment that matches production, or agreed windows if production must be tested.
- API documentation, an OpenAPI file or a Postman collection, and a list of integrations and webhooks.
- A test identity provider if single sign-on or SCIM is in scope.
- A list of what is out of bounds, such as a payment processor or a customer's own systems.
- A single person who answers our questions while testing runs, plus an emergency contact.
For the remaining basics, such as backups and notifying your provider, use our preparation checklist, or print the one-page checklist (PDF) and tick it off with your team.
07 / Price and timing
Price and timing for a SaaS test
Show details for Price and timing for a SaaS test
A SaaS product is not a starter scope: Every other test starts from INR 27,000 + 18% GST, with the exact figure set by tenants, roles, endpoints and environments. Price drivers are laid out in the VAPT cost guide, and the proposal puts scope and price on paper before work begins.
The starting price for small scopes includes one free retest. For larger scopes, the retest terms are written into the proposal before work starts.
08 / FAQ
Frequently asked questions
Short answers about scope, price and how testing works. For anything else, call +91 86868 92922.
Do you test tenant isolation in a multi-tenant application?
Yes. It is the first thing we test in a SaaS product. With accounts in at least two tenants and in each role, we check whether every endpoint, export and background job compares the record's owner with the caller, and whether any value from the request can change which tenant is used. See the section on Flaws that recur in multi-tenant products above.
Is staging enough, or must you test the live product?
Staging is enough when it mirrors production, and we usually prefer it. If a feature exists only in the live product, the scope names what is tested there and in which windows. See the section on What to prepare before the test above.
Do you test single sign-on and SCIM provisioning?
Yes, when they are in scope. We check how sign-in settings are validated, which claims the application trusts, and whether provisioning endpoints let one customer create or change users in another customer's account. You provide a test identity provider. See the section on What attackers go after in a SaaS product above.
How long does a SaaS penetration test take?
Most SaaS tests need 5 to 10 working days in total, kickoff through report. Many roles, several applications or a large API stretch that, and the proposal gives the dates. See the section on How a SaaS engagement runs above.
Will the report satisfy our enterprise customer's security questionnaire?
That is the buyer's decision, so we cannot promise it. Our executive report is written to be forwarded, and covers what was tested, how, what was found and what was retested, which is what many customers request. Ask the customer what they want before the test is scoped. See the section on Enterprise customers, SOC 2 and ISO 27001 above.
Do we need a penetration test for SOC 2?
SOC 2 does not require a penetration test. Its criteria ask for controls that find and manage vulnerabilities, penetration testing is one common way to show that, and your auditor decides what evidence is enough. See the section on Enterprise customers, SOC 2 and ISO 27001 above.
Which should we test first, the web application, the API or the cloud account?
Start with the web application and the API behind it, because that is where customers' data sits and where buyers' questions are aimed. Add the cloud account and the delivery pipeline in the same engagement or the next one. See the section on What a SaaS penetration test covers above.
Could testing disrupt our customers?
We design the work to avoid that: we prefer staging, avoid destructive payloads, and agree in writing the windows, the limits and the conditions under which we stop and call you. See the section on How a SaaS engagement runs above.
Plan your next security test
Tell us what needs testing and when you need it done, and we will propose a scope and timeline. We respond within 24 hours. If you would rather talk first, call or write to us.
- +91 86868 92922
- contact@berry9.com
- H.No: 8-3-945/A/12 & 13, Sri Venkata Sai Nest Apartments, Nagarjuna Nagar Colony, Yellareddyguda, Hyderabad 500073, Telangana