The application hid what a user should not see and enforced very little of it server side. Interface level restriction is a usability feature. It becomes a security control only when the server independently reaches the same conclusion, and here it did not.
Tenant isolation was the client's single largest concern, because a failure there is the one finding their own customers would hear about. Testing used two accounts in two separate tenants and a third with a lower role inside one of them.
Several endpoints authenticated the caller correctly and then acted on whichever identifier was supplied, without checking that the identifier belonged to the caller's tenant. Some responses differed depending on whether a record existed, which allowed identifiers to be confirmed even where the data itself was withheld.
One customer could read and in places modify another customer's records by changing a value in a request. There is no exploit chain to explain and no unusual tooling involved, which is exactly what makes this class the one most likely to be found by a curious user rather than by a tester.
None of these needs a purchase order. They are the checks that most often turn up something on a system nobody has looked at from the outside.
Hiding a button changes what a user is offered. It changes nothing about what the server will do when the request arrives anyway.
Enforcement written endpoint by endpoint holds until somebody adds an endpoint in a hurry. Enforcement in the query layer holds by default.
A 404 for a record that does not exist and a 403 for one that does tells an attacker which identifiers are real. Make them identical.
Single sign-on was configured so that the identity returned by the provider was trusted more than the account it was being attached to. The result was an account linking path that let one identity end up in control of a different user's account. This is the class of issue that reads as a configuration detail and behaves as a full account takeover.
Reviewing authentication as a lifecycle rather than a login page surfaced several issues that individually looked minor and together produced a reliable way to hold access to an account after the owner had tried to lock it down. Most of these do not appear in scanner output at all, because every response involved is a legitimate one.
Tell us what you are running and which of these worries you. We will tell you plainly whether it is worth testing, what it would cost, and when the answer is that you should fix something yourself first.
Ask about services, pricing, how an engagement runs, or what we do not do. I can also book you a call.
