The B2B SaaS Pentest Checklist: Multi-Tenant Isolation, Auth, RLS, and the 47 Things That Actually Break

A B2B SaaS pentest scope can sprawl, fast. The checklist below is what we actually run on every engagement — 47 categorical probes that, in our experience, account for >90% of the CRITICAL findings on multi-tenant SaaS products. It's organised by surface; cross-reference it against your scoping document before the engagement begins so nothing falls between the cracks.

1. Tenant boundary — the foundation

Every B2B SaaS pentest must, at minimum, log in as two organisations concurrently (Org-A and Org-B) and probe the boundary between them on every endpoint that includes a tenant identifier.

1. Sequential-id BOLA: replay GET /api/v1/<resource>/{id} from the Org-B session with an id that belongs to Org-A. Expected: 404 or 403. Actual common bug: 200 with Org-A data.
2. Opaque-id BOLA: same probe with UUID/Slug identifiers. Common bug: the “opaque” id is just a UUID4 of a freshly-created tenant resource you can guess by burning through namespace.
3. Tenant-id header swap: from the Org-B session, set X-Org-Id (or X-Tenant, X-Workspace, X-Account, etc.) to the Org-A id. Common bug: the backend trusts the header.
4. JWT claim swap: forge / re-sign a JWT with org_id = Org-A while keeping user_id of an Org-B user. Common bug: the API checks “user can read resource” but not “user's claimed org matches resource's org”.
5. Invitation-link replay: re-use a previously-consumed invitation token from Org-A. Common bug: invite tokens are single-use but org_id is encoded in the token, so a leaked token grants access.
6. Workspace-switch flow: when a user belongs to multiple orgs, verify that switching workspace fully invalidates the previous org's tokens.
7. Export-endpoint BOLA: any /export, /download, /report endpoint. Replay from Org-B with an Org-A export id.
8. Bulk-action API: POST /api/v1/items/bulk with a mixed-tenant id list. Verify the request is rejected, not partially applied.

2. Auth & SSO surface — the second-biggest source of CRITs

9. SAML assertion replay: capture a SAML response from Org-A's IdP, replay it against the SP endpoint scoped to Org-B. Verify the audience-URI binding.
10. OIDC id_token reuse: capture an id_token from Tenant-A, attempt to use it as a bearer on Tenant-B's API.
11. SCIM endpoint scope: verify SCIM /Users and /Groups are tenant-scoped; an Org-A SCIM token can only list Org-A users.
12. SCIM role-mapping privilege escalation: send a PATCH to /Users/{id} with a payload that maps the user into an admin group; verify the IdP-side mapping is enforced server-side.
13. OAuth scope confusion: for any third-party OAuth integration, verify the scopes granted to one tenant's app can't be exercised against another tenant's resources.
14. Password-reset flow cross-tenant: trigger reset for Org-A's user from an Org-B-tenant context. Verify the reset email's link is bound to the originating tenant.
15. API key prefix scope: verify a tenant's API key (pk_..., sk_...) can't be used to authenticate against another tenant's API endpoints.
16. Session token rebinding: invalidate one tenant's session, verify the token can't subsequently be re-bound to another tenant via a workspace-switch.
17. Anti-CSRF in cross-origin admin flows: state-changing requests from the admin UI must require a token bound to the session AND the tenant.
18. MFA bypass on tenant-impersonation: if your platform supports admin-as-customer login, verify MFA on the admin can't be bypassed by initiating the impersonation flow first.

3. RLS / BaaS configuration

19. Supabase RLS enabled on every tenant table: query each table via /rest/v1/<table> with the anon key. Anything that returns rows fails the test.
20. Supabase RLS policy correctness: even with RLS “enabled,” verify the policy actually scopes to auth.uid() and tenant_id, not just “auth != null”.
21. Firestore security rules: rules_version 2 with explicit tenant scoping in /tenants/{tid}/<collection>/{doc}.
22. Firebase storage bucket rules: verify match /b/{bucket}/o/{tenantId}/{rest=**} enforces request.auth.token.tenantId == tenantId.
23. Cross-region replica drift: if you use multi-region replicas, verify they enforce the same RLS as primary.
24. Database connection pooling: if you use pgbouncer or similar, verify the connection doesn't leak SET role / session_user state between tenants.
25. Search index isolation: ElasticSearch / Algolia / Meilisearch indexes must be tenant-scoped; verify a tenant's search query can't return another tenant's documents.

4. Object storage

26. S3 / GCS / Azure bucket public-listing: probe ?list-type=2 / ?comp=list / objects.list. Anything listable from anonymous fails.
27. Signed-URL cross-tenant replay: a signed URL generated for Org-A must not be reusable from any Org-B session that intercepts it.
28. Signed-URL expiry: confirm expiry actually enforced server-side, not just encoded in the URL.
29. Path prefix segregation: object keys must include tenant_id as the first path segment, AND the bucket's IAM must enforce prefix-based access.
30. Content-disposition smuggling: an attacker controls the filename on upload; verify the served Content-Disposition is sanitised to prevent header injection.
31. Pre-signed POST policy: probe whether the policy permits unintended Content-Type or Key prefixes.

5. Queues, jobs, and async pipelines

32. Job-payload spillage: a queued job carrying tenant_id in the payload — verify retries don't run with stale or wrong tenant context.
33. Webhook delivery isolation: a failed webhook retry can't be redirected to another tenant's URL via header manipulation.
34. Webhook payload integrity: HMAC-signed by tenant-specific secret, signature verified before delivery.
35. Dead-letter queue access: any DLQ inspection UI must scope to the calling tenant.
36. Scheduled-job tenant binding: cron-like jobs declared per-tenant must execute in that tenant's context, even when a worker is recycled.

6. Admin / superuser surface — where the CRITs hide

37. Admin route accessible from non-admin role: probe /admin, /api/admin, /internal — verify they require server-side admin role enforcement, not just frontend route guards.
38. Login-as-customer audit trail: immutable, attributable, and visible to the impersonated tenant.
39. Login-as-customer scope limits: the impersonating admin doesn't get PII outside policy.
40. Force-logout / kick-session admin tools: verify they can't be exercised against another admin to escalate privileges.
41. Tenant deletion / merge flows: verify they actually cascade-delete data, not just unlink.

7. Audit-log integrity

42. Audit log is append-only: verify no API surface allows DELETE / UPDATE on audit_log entries, even for admins.
43. Audit log entries are bound to actor + tenant: not just timestamp + action.
44. Audit log export is tenant-scoped: an admin can export only their own org's audit log.
45. Audit log retention: matches the compliance commitment (SOC 2 typically requires 12 months).

8. Compliance evidence chain

46. Pentest report includes reproducible curl one-liners for every CRITICAL/HIGH finding, not just prose descriptions.
47. Findings are mapped to compliance controls (SOC 2 CCs, ISO 27001 Annex A clauses, PCI-DSS requirements, HIPAA 164.312 sub-parts, NIST 800-53 controls, GDPR articles). Auditors don't want CVSS scores; they want control evidence.

How to actually run this

There are three reasonable ways to execute the checklist against your B2B SaaS:

1. Send it to your boutique consultancy as the scoping document. Any vendor that won't commit to running all 47 in their B2B SaaS pentest engagement is selling you a generic web-app pentest with a B2B SaaS label.
2. Run it via an AI penetration testing system, continuously. Most of the 47 probes are templatable; an AI penetration testing system that supports multi-tenant authenticated scanning can run the full checklist on every release. Pentestas does this on the free tier with up to 10 verified-domain scans per month.
3. Stand up an internal red-team capability. Realistic only at Series-B+ with a dedicated security hire. Use the checklist as the test plan for that team's quarterly internal pentest.

The hybrid model usually wins: penetration testing with AI runs the 47-probe checklist continuously, a manual engagement digs into the bespoke business-logic surface annually. The checklist guarantees no probe falls off the calendar; the manual engagement guarantees the parts that require human reasoning (chained business-logic bypass, financial-fraud flows, social-engineering of admin tooling) get looked at.

Where Pentestas runs the checklist for you

Pentestas is a pentesting-as-a-service platform — an AI penetration testing system built for the multi-tenant B2B SaaS pentest shape. The 47-probe checklist above isn't a paid add-on; it's the default scope on every authenticated scan. Penetration testing with Claude handles the analyst-grade reasoning that ties cross-tenant findings into an attack chain narrative (Tenant-A signed URL → Tenant-B session reuse → cross-org data export). Penetration testing with DeepSeek handles the broad-spectrum verification across the API surface at the unit cost that lets us re-run the full checklist on every release without blowing your annual security budget.

Every finding ships with a deterministic replay, a confidence-weighted evidence chain, and a compliance-control map. The report drops into SOC 2 / ISO 27001 / PCI / HIPAA evidence binders without manual cleanup. The destructive-payload guard is unconditional — no DROP, no TRUNCATE, no rm, no shutdown, no per-tenant exception. Penetration testing with AI in production has to be safer than a human consultant, not less safe.

Free tier covers the full B2B SaaS pentest checklist on a verified domain, 10 scans per month, no credit card. If you're comparing pentest providers and want to know whether your current vendor actually runs every probe in this checklist, the cheapest experiment is to run Pentestas against the same environment in parallel and diff the findings — usually we surface 2-5 multi-tenant CRITs that the generic web-app pentest missed.

• B2B SaaS Pentest: What It Is, What It Costs, and When You Actually Need One
• B2B SaaS Pentest vs Generic Web-App Pentest: What's Actually Different
• Continuous Pentest as a Service: From Annual Audit to On-Demand Security Assurance
• SaaS Penetration Testing: Why Multi-Tenant Platforms Need Specialized Security Testing