Pricing Contact Case Studies Research Talk to a Pentester ↗
PoCForge / Case Studies / SaaS tenant isolation
ANONYMISED PATTERN · SAAS · WEB & API

SaaS tenant isolation review

Anonymised pattern: multi-tenant B2B SaaS preparing for enterprise security questionnaires — with workspace isolation as the primary risk story.

Request a free scope review →All case studies
Isometric glass-walled tenant rooms on a shared platform, with an orange crack in one dividing wall and a line passing into the next room, beside the heading "SaaS tenant isolation review" and the PoCForge logo.

At a glance

  • SectorMulti-tenant B2B SaaS
  • SurfacesWeb app + authenticated APIs
  • Duration classFocused web+API window
  • RetestScheduled priority retest

Context

A product team needed web and API testing before a set of enterprise deals. Primary concern: whether users in one workspace could read or modify another tenant’s data through IDOR-style access, invitation flows or admin workflow confusion. Staging mirrored production authorisation models. The buyer needed a report suitable for customer security questionnaires — not a raw scanner dump.

Empanelment was not a contractual requirement; evidence quality and retest closure were. That matches many India SaaS buyers described on our SOC 2 / ISO VAPT guide and commercial page for VAPT services in India.

Engagement shape

Typical shape for this pattern: a focused web+API assessment over a defined feature set (workspaces, members, shared objects, billing-adjacent reads), two to three authenticated role families, and a fixed retest window after priority fixes. Scope excluded destructive production testing and third-party IdP hardening beyond how the app consumed assertions.

Kick-off clarified success criteria: “can a neighbour tenant reach our data?” mattered more than a long list of low-impact header findings. That clarity is exactly what our VAPT RFQ checklist pushes buyers to write down early.

Approach

SaaS tenant isolation review: engagement pathSaaS tenant isolation review, in five steps: discover, validate, prove, remediate and retest. Illustrative, anonymised pattern. 01DiscoverMap workspaces,roles and objecttypes that carrytenantboundaries.02ValidateAuthenticatedrole testing andcross-tenantidentifier checkson UI and API.03ProveEvidenceunauthorisedread/writecapability instaging — noproductiondestruction.04RemediateServer-sidetenant binding,invitationhygiene, exportpredicates.05RetestConfirm priorityisolationfindings closed;residual itemsowned.Illustrative. Anonymised pattern; real steps depend on scope.
SaaS tenant isolation review: engagement pathSaaS tenant isolation review, in five steps: discover, validate, prove, remediate and retest. Illustrative, anonymised pattern. 01DiscoverMap workspaces, roles and object types thatcarry tenant boundaries.02ValidateAuthenticated role testing and cross-tenantidentifier checks on UI and API.03ProveEvidence unauthorised read/write capability instaging — no production destruction.04RemediateServer-side tenant binding, invitationhygiene, export predicates.05RetestConfirm priority isolation findings closed;residual items owned.Illustrative. Anonymised pattern; real steps depend on scope.
Read the steps as text
  • Step 1

    Discover

    Map workspaces, roles and object types that carry tenant boundaries.

  • Step 2

    Validate

    Authenticated role testing and cross-tenant identifier checks on UI and API.

  • Step 3

    Prove

    Evidence unauthorised read/write capability in staging — no production destruction.

  • Step 4

    Remediate

    Server-side tenant binding, invitation hygiene, export predicates.

  • Step 5

    Retest

    Confirm priority isolation findings closed; residual items owned.

Finding classes (illustrative)

Without disclosing exploit detail: cross-tenant object access via predictable identifiers; privilege confusion where UI hid actions the API still accepted; invitation tokens that broadened access beyond the intended seat; export jobs that assumed UI filters equalled server-side tenant filters. Severity was framed by data sensitivity and whether an ordinary authenticated user could reach another tenant’s records.

The useful artefact for buyers was a prioritised list with reproduction steps engineering could run.

Fictional sample report page with a finding card showing evidence, impact and fix

Outcomes and remediation pattern

Engineering prioritised server-side tenant binding on every sensitive object route, tightened invitation token lifetime and aligned API authorisation with UI role matrices. Export and reporting paths gained explicit tenant predicates. A remediation retest confirmed closure of the agreed priority findings and left residual lower-priority items with clear owners. Leadership received an executive summary usable in questionnaire responses.

Exact logos and confidential payloads are withheld. If your multi-tenant model needs a similar shape, start with web VAPT India, API security testing India, or a combined programme via VAPT services.

Lessons for buyers

  • Ask vendors how they will test tenant binding, not only OWASP Top 10 labels.
  • Require API coverage whenever the UI is a thin client.
  • Budget a retest — questionnaire reviewers increasingly ask whether fixes were verified.
  • If CERT-In empanelment is not required, say so; buy evidence quality instead. See the CERT-In guide.

Why this pattern shows up in India SaaS deals

Enterprise questionnaires in India and globally increasingly ask how multi-tenant isolation is tested — not only whether a vulnerability scan was run. Buyers who arrive through VAPT India searches often need a narrative they can reuse with customers: what was in scope, what class of issues mattered, and whether fixes were retested. Pair this write-up with web application pentesting India when isolation is primarily an application concern, or with desktop India when an Electron client also stores tenant context locally.

Related reading