Ask a team for their API inventory and you'll get an OpenAPI file. Then look at what the front end actually calls.
They rarely match. Endpoints added for one feature. Old versions nobody removed. Admin routes that are "only used by the dashboard." Plenty of them never make it into a spec, but every one of them is sitting in the JavaScript bundle your users download.
Attackers read that bundle. A dynamic scanner should too.
What changed in Safeguard DAST
It keeps the full shape of what it finds. When the scanner discovers an API call in JavaScript, it now keeps the method, the body shape and the content type, not just the URL. That matters. A POST with a JSON body behaves very differently from a GET to the same path, and testing the wrong one misses the bug.
It uses what it has already seen. Broken object level authorization, where you change an ID and get someone else's data, is the most common serious API flaw. To test for it you need realistic IDs. The scanner can now seed its enumeration with identifier patterns from data the crawl has already observed, then confirm a finding end to end before reporting it.
One big domain can't eat the budget. Crawl capacity is now reserved per host. A single large application no longer uses up the scanning time meant for the rest of your estate.
Why confirmation matters
A scanner that reports "possible IDOR" on every numeric parameter gets ignored within a week. Confirming end to end means the finding comes with proof that the request worked when it shouldn't have. Fewer findings, but ones people act on.
Try it yourself
DAST runs against web apps and APIs you own and have verified.
Click through it at your own pace, or open it full screen.
Open your own web app, open the browser's developer tools, and search the loaded JavaScript for "/api/". Count the paths you find and compare them with your API spec. Any path that's in the bundle but not the spec is one your scanner should be testing. Next: a DAST web app scan.
Quick check
Why does the scanner keep the method and body shape, not just the URL?
Because a POST with a JSON body and a GET to the same path behave differently. Testing the wrong one misses the bug.
What does confirming end to end add to an IDOR finding?
Proof that the request actually returned data it shouldn't have, so the finding isn't just a guess based on a numeric parameter.
