Applications

SaaS application pentest

A multi-tenant test built around the question your own customers ask in their security reviews: can anyone using your product reach data that belongs to someone else? We sign up as two tenants and try.

Book a scoping call All services

areas covered

stages, scoping to retest

In-house

testers, never subcontracted

portal.cyberlysecure.com/acme-health/coverage

Acme Health — Test coverage4 practices · 15 services · one team

In-house

Web app

API

SaaS

Mobile

Client-side

External

Internal

Segment test

Wireless

Cloud config

Hardware & IoT

AI & LLM

Social eng.

Physical

Red team

ApplicationsNetworkCloud & devicesPeople & premises

6 in scope · one team · one report

In-house testers 0 subcontracted

Every surface one team

What this is

What the test covers.

Everything in a standard web application test applies to a SaaS product — and then tenancy sits underneath all of it. Isolation has to hold in the database, in the cache, in background jobs, in file storage, in exports and in every integration you offer.

We test with two live tenants side by side, which is the only way to prove separation rather than assume it. The report is written so you can hand it straight to a customer or an auditor.

OWASP Web Security Testing Guide OWASP API Security Top 10 OWASP ASVS

What we test

Cross-tenant data access through identifiers, filters, exports and search
Tenant context in caches, queues, background jobs and file storage
Roles and permissions within a tenant, including owner, admin, member and read-only
Single sign-on (SAML, OIDC) and SCIM provisioning and de-provisioning
Invitation, onboarding, trial and account-deletion flows
Subscription, quota and entitlement enforcement
Audit logging — whether a tenant admin can see what actually happened
Integrations, API keys and webhooks issued per tenant

How it runs

From scoping call to retest, here’s what happens.

Typically one to three weeks, depending on role matrix, integrations and plan tiers.

Scope and authorize

We agree the environment, the plan tiers in scope and the test window in writing.

Stand up two tenants

We work from two separate tenants with the full role matrix in each, so isolation is tested rather than assumed.

Cross every boundary we can

Identifiers, tokens, exports, uploads, integrations and background jobs are all tested for leakage between tenants.

Test the tiers

We check whether paid features, quotas and seat limits hold when the client stops cooperating.

Report, readout and retest

You get a report suitable for customer security reviews, a readout and a retest of your fixes.

What it surfaces

The kind of thing this test tends to find.

Real examples of what this engagement uncovers — anonymized, and never every time. What matters is that you find out before somebody else does.

A tenant identifier accepted from the client and trusted by the server

Exports, reports or search indexes that were never scoped to one tenant

SSO configurations that let an attacker-controlled domain assert your users

De-provisioned users keeping access through an old token or API key

Plan limits enforced only in the interface

Getting started

What you get, and what we need from you.

What you get

Technical report — Every finding, the evidence behind it and clear guidance your engineers can act on.
Executive summary — Your risk explained in plain language for leadership and the board.
Attestation letter — Signed confirmation of testing to hand your auditors.
Readout call — A walkthrough with the people who tested your systems.
Retest — Confirmation your fixes worked, documented for whoever needs to see it.

What we need from you

A staging environment with production-like data separation
Two tenants, each with accounts covering every role
SSO test configuration if it is in scope
One named contact for the duration of the test

Missing something on this list? Bring it to the call — we scope around what you have.

Others in Applications