SaaS & Technology Penetration Testing

We map the application, its APIs, its single-sign-on paths and any exposed internal or admin surface using Burp Suite, ffuf and manual review of the front-end code. Then we set up the accounts that make cross-tenant testing possible: two or more organisations, users at every permission level, and where relevant an SSO connection so we can attack the federation flow.

This is the core of a SaaS engagement. We take every object identifier the product exposes and try to reach it from the wrong tenant and the wrong role. We swap organisation IDs, replay another tenant’s API calls with our own token, and probe GraphQL nodes and batch queries for objects we should never see. A single cross-tenant IDOR here is often a critical finding on its own.

Where isolation usually breaks

The gap is rarely the primary record. It hides in the second-order surfaces: exported reports, file downloads served by ID, background jobs that email results, audit logs, and search endpoints that index every tenant into one store. We test those alongside the obvious CRUD routes, because that is where an isolation model quietly leaks.

We attack the login and federation layer: SAML response tampering and signature-wrapping, OAuth redirect and scope abuse, JWT algorithm confusion, and whether a session survives a password change or an SSO revocation. Account takeover through a weak reset token or a reusable magic link is a recurring theme.

Where we find a way across the tenant boundary or up the role ladder, we prove it with a real request set and a screenshot of another tenant’s data reached from our account, using only test records. You get the written report within days, a live walkthrough, and a free retest after you fix.

An endpoint that fetches a record by ID but forgets to check which tenant owns it is the classic SaaS breach. We systematically test object references across tenants, including nested resources, exported files, and API responses that over-share fields. When cross-tenant IDOR exists, one customer can read or edit another’s data, and that is the finding that ends up in a breach notification.

Admin-only actions that are hidden in the UI but reachable by a direct API call let a low-privilege user promote themselves, change billing, or manage other users. We map the full permission matrix and test every privileged function from every lower role.

SAML and OAuth are easy to integrate and easy to get subtly wrong. We find missing audience checks, unsigned or weakly signed assertions, redirect URIs that leak tokens, and JWTs that accept the “none” algorithm or a swapped signing key. Any of these can hand an attacker a valid session in someone else’s organisation.

APIs that bind request bodies straight onto models let a user set fields they should never control, such as their own role, tenant ID or account status. We test create and update endpoints for hidden parameters and for responses that leak more than the UI shows.

Business-logic testing covers whether trials can be reset indefinitely, whether paid features open up without payment, whether quotas and seat limits can be exceeded, and whether the invite or SCIM flow lets an attacker join an organisation uninvited. These flaws cost revenue quietly and rarely show up in a scan.

Outbound webhooks and third-party integrations are a common server-side request forgery vector, letting an attacker pivot toward internal services or cloud metadata. We test URL validation on webhooks, signature verification on inbound callbacks, and how you store the OAuth tokens your integrations depend on.

SOC 2 (Trust Services Criteria) and ISO 27001 both expect regular independent testing of the application and evidence that findings are remediated. Our report and attestation letter give your auditor exactly that: scoped testing, risk-ranked findings, and confirmation of fixes at retest. ISO 27001 control A.12.6 on technical vulnerability management maps cleanly to this work.

We measure against OWASP ASVS and the OWASP API Security Top 10, which is squarely aimed at the broken-authorization issues that dominate SaaS. For any mobile clients we use OWASP MASVS. These give your engineers a shared, well-documented reference for each fix.

Because you process customer and often personal data, GDPR obligations shape how we test and report, and the results double as evidence for the security questionnaires your enterprise prospects send. For regulated customers, the report also supports DORA third-party resilience expectations.