The starting point
The company's platforms are its business: web applications through which customers access its data products, and APIs that distribute them programmatically. Every customer — institutional and corporate organisations with very high security expectations — operates on the same shared platform. In a model like that, one question keeps people awake at night: can customer A see, through any route whatsoever, customer B's data?
It was no theoretical worry. Several of its customers contractually required periodic penetration tests by an independent third party, and renewals were starting to ask for evidence. A pentest was agreed with a signed scope and rules of engagement: which systems, which techniques, which time windows, and an immediate notification channel in case anything serious surfaced mid-test.
How we approached it
- Reconnaissance and threat modelling — a map of the exposed surface and the platform's data flows, to decide where a real attacker would strike first: customer accounts, distribution APIs and perimeter infrastructure. Tests were prioritised by business impact, not by catalogue.
- OWASP testing of the web applications — authentication, session management, injection and, above all, access control: what each role can do, and what a legitimate account can reach beyond what it should.
- Focus on tenant isolation — the engagement's central test: using legitimate accounts belonging to one customer, attempting to reach other customers' data, jobs and metadata through every route — predictable identifiers, object-level authorisation, incomplete filtering in listings and search.
- Abusing the data-distribution APIs — object-level authorisation on every endpoint, consumption limits and quotas (can I download more than I have contracted?), and abuse of the programmatic distribution's business logic.
- Exposed infrastructure — inventory and testing of every service reachable from the internet, including those that should not have been: admin panels, auxiliary environments and forgotten services.
- Report, remediation plan and retest — every finding with reproducible evidence, impact and a recommended fix, plus an executive summary for management. After remediation, a formal retest of each vulnerability and written certification of closure.
Results
11
vulnerabilities identified and documented with reproducible evidence
2 high
remediated and verified through retest in under three weeks
1 requirement
the pentest report became a standard piece of its renewals with institutional customers
Of the 11 vulnerabilities, none was critical and exploitable without authentication — but the two high-severity findings landed exactly where it hurts most. The first: an access-control weakness that allowed a legitimate account to reach metadata of other customers' jobs — not the data itself, but enough to reveal what each customer was ordering and when. The second: internal administration endpoints reachable from the internet behind weak authentication. The rest — several medium and low findings — was documented with the same reproducible evidence and a prioritised remediation plan.
The client's team fixed both high-severity findings in under three weeks, and the retest verified the closure of both. The commercial effect came later: the report — findings, fixes and closure certified by an independent third party — became part of the standard package the company presents in its renewals with institutional customers. What began as a requirement turned into a selling point.
What made it work
- On multi-tenant platforms, isolation between customers is THE test that matters: a single cross-tenant leak outweighs ten catalogue findings.
- Data APIs are simultaneously the product and the attack surface: testing them as a malicious customer would is testing the business itself.
- A periodic pentest stops being an expense the moment your own customers demand it as a guarantee: it becomes a commercial asset.
Frequently asked questions
What gets tested in a pentest of a multi-tenant data platform?
Everything an attacker — or a malicious customer holding a legitimate account — might attempt. On the web applications, the usual OWASP battery: authentication, session management, injection, access control. On the data APIs, object-level authorisation (can I request resources that are not mine by changing an identifier?), consumption limits and business-logic abuse. And the test that matters most in multi-tenancy: isolation between customers — using a legitimate account on tenant A, attempting to reach tenant B's data, jobs or metadata through every available route.
What are rules of engagement and why do they protect both parties?
A document signed before anything starts, defining which systems are in scope, which techniques are permitted, in which time windows testing happens, what is explicitly off-limits, and who gets notified immediately if something serious surfaces mid-test. They protect the client because they guarantee the testing will not harm operations or its own customers' data; and they protect the pentesting team because they legally delimit an activity that, without written authorisation, would be a crime. Without signed rules of engagement there is no serious pentest.
What does the client receive at the end of the pentest?
Two reports and a verification. A technical report with every vulnerability documented: description, step-by-step reproducible evidence, impact and a concrete remediation recommendation, prioritised by real risk. An executive summary in business language, written for management and for customers asking for assurances. And a retest included: once the client remediates, we test every finding again and certify in writing what has been closed.
Can the pentest report be used with customers and auditors?
Yes — and in this case it became exactly that. A report from an independent third party, with a recognisable methodology, documented findings and closure verified through retest, is evidence an institutional customer or an auditor can weigh. It is not a decorative badge: it demonstrates that the platform undergoes periodic offensive testing and that findings get fixed within concrete timeframes.
Related services
Would your platform withstand a malicious customer?
Our pentesting probes your applications and APIs the way an attacker with a legitimate account would: tenant isolation, object-level authorisation and exposed infrastructure. With reproducible evidence, a retest included and a report you can show your customers.