Two classic injection classes, both reachable only after login, which is why neither had ever been reported by an unauthenticated scan. The database defect exposed data across the whole application. The scripting defect ran in the browser of whoever reviewed the affected record, which in this product was always an administrator.
Most automated testing on this product had been unauthenticated, so it had only ever exercised the marketing pages and the login form. Testing here started from a normal low-privilege account, which is the position a real attacker reaches by signing up.
One reporting parameter reached the database without parameterisation, allowing controlled query behaviour and read access beyond the tenant the account belonged to. Separately, a free text field was stored unencoded and rendered into an administrative review screen, so content submitted by an ordinary user executed in an administrator's session.
The first gave read access to data belonging to other customers from an account that only ever paid for its own. The second gave an ordinary user a path to actions in an administrator's browser, in their session, with their permissions. Chained, a self-registered account reaches the top of the application.
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.
If your product is behind a login, the interesting surface is behind that login too. Testing needs credentials for every role, or it is not testing your product.
Stored cross-site scripting that only ever renders back to its author is a low finding. The same defect rendering into an administrator's screen is a path to the whole system. The difference is workflow, not code.
Sort fields, column names, export selectors and pagination values arrive from the browser. They are as controllable as a search box and are far less likely to have been reviewed.
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.
