Why your scanner has one login, and where authorization testing fits.

A quiet report is not a clean one

Open the last report your scanner produced and look for findings about who can reach what. For most teams there are none, and it is tempting to read that as good news. It is neither good nor bad news. It is a question nobody asked. Authorization testing, which means checking that each signed-in account reaches only what it should, needs information a scanner is never given. Its silence on the subject tells you about the tool, not about your application.

None of this is an argument against the scanner. It is an argument about what its report can and cannot mean, so that you can decide what belongs next to it.

What a dynamic scanner actually does

A DAST tool is handed a starting address and, usually, one set of credentials. It signs in, crawls whatever it can reach from there, and sends input designed to make the application misbehave: a string that breaks out of a database query, a script that ends up rendered in a page, a path that climbs out of its folder. Then it reads the responses for signs that something gave way.

Draw it and it is a single line. One session, one crawl, one picture of the application. Whatever that one account can see becomes, for the length of the scan, the whole product.

Some tools can hold a second set of credentials, and a careful team can run a separate scan for each type of account. That helps with coverage. It does not change the underlying problem: the tool is never told which records belong to whom, so it has nothing to compare one account's answers against.

What it is genuinely good at

Scanners deserve more credit than newer vendors tend to give them. A mature one carries a large library of checks, kept current by people whose whole job is keeping it current. It is strong on injection, on components with known vulnerabilities, on missing headers, weak TLS settings, exposed admin pages and default files. It tests what you actually deployed, configuration included, which beats reading a repository and hoping production matches.

Run on a schedule, it also catches the regressions that arrive with a dependency upgrade or a configuration change pushed late on a Friday. If your team does not run one today, that is the gap to close first, before anything we would sell you.

What it cannot know

Here is the structural part. A scanner has never been your reseller, your support agent, your finance approver or a stranger with no account at all. It does not know that a reseller should see their own clients and nobody else's, or that support may open a customer's profile but not their payment details. Those rules live in your code and in your team's heads. Nothing in an HTTP response says them out loud.

So when a request for invoice 5120 comes back 200 OK, the scanner sees a page that works. Whether it is a bug depends entirely on who asked and who owns invoice 5120, and that is exactly the context the scanner was never given. The request is valid, the response is valid, and the leak is invisible from where the tool is standing.

Two kinds of bug live in that blind spot

Who can reach what. One signed-in account reading or changing another account's data: an invoice number swapped in a URL, a user ID edited in a request body, an admin-only endpoint that checks you are signed in but not that you are an admin. OWASP groups this family under broken access control and ranks it first in its Top 10 (2021), A01. Its API list puts broken object level authorization at the top as well (API1:2023). Nothing about the requests looks unusual, which is why they pass through tools that look for unusual requests.

Whether the maths is right. Business-logic flaws: two discounts that were never meant to combine, a negative quantity that turns into a refund, a monthly allowance that resets on a downgrade. Every request is well formed and every response is a success. There is no signature for "this order should not exist", so a tool built on signatures has nothing to match.

The same app, drawn twice

Draw your own application from each side and the difference is easy to see.

The two views barely overlap, and that is the whole case for running both. We have taken the second view apart in detail elsewhere. This post is about how it sits next to the first.

Authorization testing beside DAST, in practice

Same applications, different questions. The scanner runs on its schedule across everything you expose. Authorization testing goes deepest on the applications where one account holds data that belongs to someone else: anything with more than one customer in the same database, anything with a support or reseller role, anything that moves money.

Different inputs. A scanner needs an address and a login. Authorization testing needs one working account for each type of user, plus a sentence on what each one is for. Collecting those accounts is most of the set-up work. It is worth doing once, properly, because the same accounts serve every test after it.

One queue at the end. Findings from both should land in the same backlog, on the same severity scale, with CWE references so nothing is counted twice. Do not ask either tool to be the other, and do not treat a clean result from one as a clean result from both.

On budget, the honest framing is that the two are not competing for the same line. One buys breadth across problems that are already known. The other buys depth on a question breadth cannot answer.

That second view is the one Cyberlop is built for. It finds vulnerabilities in web apps and their APIs, checks cross-account access, and when it can read your code it does so while testing the running app, so a finding points to the file and line that allowed it.

Honest limitation

We cover a narrow set of vulnerability classes on purpose. If your biggest risk is an unpatched component, an exposed service or a misconfigured server, a scanner is the right tool and we are not. We do not scan networks or infrastructure, and on a wide estate of older targets a broad scanner will find things we will not.

Authorization testing also depends on the accounts. A missing account type means a missing set of answers, and any tester, human or otherwise, should tell you which ones were not covered rather than leave a quiet gap. And it proves that a rule was not enforced. Whether the rule is the right one for your business is still your call.

We have not published a detection rate for any of this, and we are not going to make one up. What we have not proved yet →

Monday-morning actions

1. Count. Open your last scanner report and count the findings about access: one account reaching another's data, or a low-level account reaching a high-level action. If the count is zero, write "not tested" next to it, not "passed".

2. List. Write down the types of account your product has, such as customer admin, customer member, support, reseller, finance and no account at all. Mark which ones your scanner has ever held a session for.

3. Try ten requests by hand. Take two accounts in two different customer organisations. Using account A's session, request five things that belong to B: an invoice, a user profile, a file download, an export and a settings page. Then do the reverse. Ten requests, about an hour. Any response that hands back B's data to A is a finding, so save the request and the response.

4. Put both on the calendar. The scanner on its schedule, and authorization testing whenever your roles, your sharing features or your ownership checks change.