Article 21 of OUG nr. 155/2024 lists the testing and auditing of security measures among the obligations of an essential or important entity. DORA's Article 24 asks financial entities for a testing programme. Neither says how, which leaves a practical question for whoever signs the attestation: what does a clean vulnerability scan actually let you claim?
Less than most people assume, and the gap is not about coverage percentages. It is about what a scanner can observe at all.
The detection method decides the finding
Almost all automated testing works on the same loop: send a request, read the response, decide whether the response looks wrong. Error text, a stack trace, a reflected payload, an unexpected status code.
That loop has a blind spot built into it. Two large families of serious vulnerability return a response that looks entirely normal, and a tool that decides by reading responses will therefore report nothing on both. Not as a tuning problem, and not something a longer scan window fixes — the evidence is simply not in the reply.
By the published 2025 figures, those two families account for the largest share of API vulnerabilities found all year.
Family one: the effect lands somewhere you are not looking
An endpoint accepts a URL — an import feature, a webhook, a document generator that fetches a logo, a link preview. The server fetches the address it was given and returns its usual 200 OK, because as far as the application is concerned the operation succeeded.
What it also did was issue a request to a destination a stranger chose. Pointed at an internal administration interface, a cloud metadata endpoint that dispenses credentials, or a database reachable from inside but not outside, the server fetches that too. The response to the attacker stays generic. Nothing about it is anomalous.
Server-Side Request Forgery, the formal name for this, was present in 33% of the API vulnerabilities published in 2025. The pattern recurs in other classes: a command that executes without printing, a query that runs while the page renders identically either way, a script that fires days later in an administrator's browser. These are the blind or out-of-band flaws, and the term is literal — the proof never returns through the channel the tool is watching.
Finding them requires giving up on the reply. The method is to hand the application a uniquely generated hostname pointing at a listening server, then watch that server. If anything ever connects, the application performed the action. The connection is the evidence; no response is needed. This is out-of-band application security testing (OAST), and it has two hard requirements: callback infrastructure the tester controls, and a distinct address per test so each interaction maps back to the request that caused it. Testing without the first cannot find these flaws; without the second it finds them without being able to say where.
For an assurance file, that distinction matters in a useful direction. A finding derived from an error message is an inference. A server that reached out and contacted a host it had no business contacting is an observed fact, with a timestamp.
Family two: a valid response issued to the wrong party
The second family defeats response analysis for the opposite reason. Nothing malfunctions. The application answers correctly — to someone who should not have asked.
A logged-in user requests /api/invoices/1042, their own. They request 1043, which belongs to another customer, and receive it. The API verified authentication and never verified ownership. That is Broken Object Level Authorization (BOLA), present in 39% of API vulnerabilities published in 2025 and the largest single category above. Its counterpart, Broken Function Level Authorization (BFLA), applies the same failure to operations rather than records: a standard user reaching an administrative endpoint, or issuing a method the interface never offered them. The screen withheld the button; nobody confirmed the server would withhold the action.
What a single-session scanner observes when it requests invoice 1043 is a valid invoice. Well-formed, correctly typed, 200 OK. There is no malformation to match on and no anomaly to score. The response is only wrong in a way that depends on information the tool does not hold — who owns the record.
Detecting it needs at least two authenticated identities, a map of what each is entitled to, and a comparison between them: retrieve an object as its owner, retrieve it again as an unrelated account, and examine whether the second account received the same data. The vulnerability exists in the difference between identities. No amount of analysis of one session can surface it, which is why broad-spectrum scanners generally do not attempt it and why authorization findings dominate manual test reports.
What breaches did, as distinct from what scanners count
Vulnerability counts and incident causes are different datasets, and conflating them is how programmes end up well-defended against the wrong thing.
Across 60 API-related breaches disclosed in 2025, broken authentication accounted for 52% and unsafe consumption of third-party APIs for 27%. Authorization failure appears lower, at 10%, which is worth reading carefully rather than as reassurance: BOLA is the leading category by volume of vulnerabilities and a smaller share of disclosed breaches, because it tends to produce quiet enumeration and scraping rather than the kind of event that forces disclosure. The Condé Nast incident in that dataset — object-level authorization abused to enumerate and scrape subscriber records — is the shape it takes when it does surface.
Two obligations follow directly. Unsafe consumption at 27% is a supply chain finding, and it maps onto the supply chain security measures in Article 21 rather than onto anything a scan of your own perimeter will reveal. Improper inventory management at 12% is the forgotten-endpoint problem, which is why an asset inventory is a control in its own right and not administrative overhead.
Questions that establish what a scan covered
When a report arrives, or a provider is being selected, four questions separate testing that could have found these classes from testing that was never positioned to.
- Is out-of-band testing performed, with callback infrastructure? If not, the blind classes were outside scope regardless of report length, and the file should record that rather than imply coverage.
- How many authenticated identities were used? One means authorization testing did not occur. Two or more, with a defined entitlement map, means it could have.
- Were authenticated endpoints reached at all? Unauthenticated surface scanning says nothing about logic behind a login, and most business-critical endpoints sit behind one.
- Can each finding be traced to the request that produced it? For an out-of-band result this is the correlation between callback and payload, and it is what makes a finding defensible at an inspection.
An honest negative result is more useful than an implied one. "Authorization testing was not in scope for this scan" is a defensible line in a risk register. A clean report that silently never tested authorization is the thing that fails an audit later, because the control was recorded as verified when it was not examined.
Where the line sits
Automation is well suited to both of these families — OAST for the blind classes, multi-identity replay for the authorization classes — and both are part of what ClickScan runs, with its own callback infrastructure and separate test identities. What automation establishes is that a specific check ran against a specific endpoint and produced a specific result, repeatably and at whatever cadence you set.
What it does not establish is whether the authorization model is correct in principle: whether the roles make business sense, whether a chain of individually acceptable permissions adds up to something unacceptable, whether a workflow can be completed out of order. Those are judgement questions, and they are what a penetration test of an API is for, alongside a recurring vulnerability assessment for the part that should run on a schedule. The governance and evidence layer — scope statements, entitlement maps, what the file shows at an inspection — belongs with audit, risk and compliance work.
The useful framing for a board is not how many findings a scan produced. It is which questions the method was capable of answering, and which were never asked.
Sources: Wallarm API ThreatStats Report 2026 · OWASP API Security Top 10 (2023)
Percentages come from Wallarm's analysis of 67,058 security bulletins published in 2025, of which 11,053 were API-related, and from its review of 60 API-related breaches disclosed the same year. OWASP categories co-occur within a single vulnerability, so the vulnerability figures do not sum to 100%. We have not independently verified Wallarm's dataset.
This article is general information, not legal or regulatory advice.