Case Study: The Auth Bug That Exposed Data Across a Multi-Tenant SaaS Platform

This case study is based on a real penetration test. The client, its product, and its customers have been anonymized to protect confidentiality.

The situation

A B2B SaaS company had launched a new product, a multi-tenant platform where each customer had its own users and its own data inside the same application.

The push for a penetration test came from customers evaluating the new product. They wanted independent security testing before committing to it.

The company also had a SOC 2 observation window coming up, so the test was scheduled to serve both purposes. It would provide security evidence for customers and prospects while also giving the auditor the evidence they needed.

The engagement

Asteros performed a web application penetration test over ten business days, using the OWASP Application Security Verification Standard (ASVS) as the testing framework.

The engagement included authenticated testing with provided credentials. The two internet-facing hosts in front of the application were also assessed.

The agreement included the full penetration test report, validation retesting of remediated findings, an updated report, and a debrief call.

What testing found

On a multi-tenant platform, one of the first questions a penetration test should answer is pretty simple.

Can one customer access another customer’s data?

We start there.

Within the first day, the answer was yes.

Logged in as an ordinary user at one organization, with no administrative privileges, we were able to access information belonging to other organizations on the platform. This included organizational details, staff contacts, and customer data.

None of this appeared in the application’s interface.

The restriction existed in the UI. Behind it, the application would still return the data if a user made the right request directly.

The problem also wasn’t limited to one other organization. The same weakness made it possible to determine which other organizations were using the platform, turning a single authorization flaw into visibility across the broader customer base.

The interesting part was the authorization logic

The application actually had the right protection in some places.

For certain requests, attempting to access another organization’s data correctly resulted in an “insufficient permissions” response. The authorization check existed. It just wasn’t being applied consistently.

This is one of the more dangerous varieties of security bug because everything looks fine when you’re looking at one feature at a time.

A developer checks a request. The application refuses access. Excellent.

Then another endpoint gets built six months later. It returns the same sort of data, but somebody forgets to make the same check.

Now the application has two security policies. One is written down in code. The other exists mostly in everyone’s memory.

Memory is a surprisingly popular access-control mechanism.

The fix

The remediation was straightforward. Enforce the ownership check centrally on the server so that every request is validated against the user’s organization, regardless of which feature or endpoint receives it.

That is considerably safer than relying on individual application features to remember to perform the check themselves.

Why it mattered

This is the kind of finding a multi-tenant company least wants a customer to discover first.

The product was new, and customers were being asked to trust it with sensitive information. They had specifically requested independent penetration testing before committing to the platform.

If a customer, or anyone with a single valid account, had discovered the vulnerability first, the conversation would have been very different.

It would no longer be a penetration-test finding. It could have become a security incident affecting data belonging to multiple customers.

Found during a controlled test, it was a fix.

Found another way, it could have become an incident, a customer notification, and a very unpleasant meeting involving people who normally only appear on the calendar when something has gone badly wrong.

How it was handled

The critical finding was confirmed and reported to the client as an interim finding on the first day of testing.

We did not wait until the final report two weeks later.

That may sound obvious, but interim reporting is less common than you might expect. Part of the reason is incentive. A critical finding that has already been remediated by the time the final report arrives makes for a less dramatic presentation. There is more theater in unveiling a critical finding to the executives than in announcing that the engineering team found out about it two weeks ago and already fixed it.

There is also a more mundane problem. At larger firms, the person who finds the vulnerability may not be the person who is allowed to tell the client about it. The finding can make its way through a project manager, a technical manager, a quality review, or a delivery team before anyone is permitted to send it out.

Those review processes have value. Careful review is important, particularly when producing a report that a client may rely on for security decisions, procurement, or compliance. But a quality process should not mean waiting days to tell a client about a critical vulnerability that is sitting in production.

The approach here is to do both. Serious findings are communicated quickly, while the normal review process continues for the final report. The tester who found the vulnerability can explain what was discovered, why it matters, and what evidence supports it without waiting for the entire engagement to be packaged and delivered.

That is a deliberate operating principle. The goal is to stay rigorous without becoming slow.

Every hour spent waiting for an internal review is another hour the client could have spent fixing the problem.

The client understood the severity immediately, which meant remediation could begin while testing continued. The rest of the engagement proceeded while the development team worked on the authorization issue.

It also meant the final report was less dramatic than it might otherwise have been. The critical finding was already known, fixed, and subsequently validated.

That is perfectly fine with us.

The purpose of a penetration test is to find problems while they are still problems the client can fix, not to save them up for a better presentation.

Alongside the findings, the report included a full ASVS assessment.

That assessment also documented where the application was doing things correctly. No injection vulnerabilities were identified within scope. TLS was well configured. Credential recovery was securely implemented. The application’s token implementation resisted the standard attacks tested during the engagement.

The result was more than a list of things that were wrong. It gave the client a documented picture of what had been tested, what needed attention, and where the application was already performing well.

Takeaways for technical leaders

A multi-tenant application makes authorization a central security concern

When many organizations share one application, an authorization flaw can expose data across organizational boundaries.

Access control isn’t just another security feature. It is part of the product’s fundamental promise to every customer.

If the application gets this wrong, it doesn’t matter how impressive the rest of the security program looks.

“The control exists” is not the same as “the control is applied everywhere”

The application had authorization checks. Some of them worked correctly.

The problem was that they weren’t consistently enforced.

This is a common failure mode in growing applications. A security control gets implemented correctly in one place, then gradually becomes a collection of assumptions elsewhere.

Testing is how you find the places where those assumptions break.

Scanners don’t understand ownership

Automated tools are useful for finding known technical weaknesses. They are much less useful for answering questions like this.

Should this particular user be allowed to see this particular record?

That requires understanding the application’s users, roles, organizations, resources, and business rules.

It requires testing the application as an attacker would, not just checking whether known vulnerability signatures appear in the response.

A scanner can tell you that an endpoint exists.

It is considerably less likely to understand that Bob from Company A has no business looking at Susan’s records from Company B.

Interim reporting matters

A critical finding reported on day one gives the client an opportunity to start fixing it on day one.

Waiting until the final report would have meant carrying the same exposure for the remainder of the engagement simply because that is when the report was scheduled to be delivered.

When something serious turns up, the client should know.

This seems obvious, which is usually a good indication that it ought to be written down.

One penetration test can serve more than one purpose

The engagement was scheduled around the client’s SOC 2 observation window, but the resulting report also gave the company independent security evidence it could use with customers and prospects.

That is one of the advantages of doing the work properly the first time.

The auditor gets evidence that testing happened.

The engineering team gets useful findings.

And the company gets a report it can keep when the next customer asks, “Have you had an independent penetration test?”

Which, sooner or later, somebody usually does.

Is your pentest testing what matters?

If you run a multi-tenant product, the question “can one customer see another customer’s data?” deserves a direct answer from someone who has actually tried. Get in touch to scope a test, or download our free guide, Audit-Proof Your Pentest, to see what a rigorous engagement should look like before you choose a vendor.