Topic starter
02/08/2026 9:43 am
TL;DR: Standard crawling still misses hidden and authenticated application paths, so DAST coverage depends on more than link following, according to StackHawk. DAST workflows need governed discovery inputs so scan reach expands without turning pipeline execution or route injection into new operational risk.
Editorial analysis by NHI Mgmt Group, based on content published by StackHawk: “Customized and Configurable Scan Discovery”.
Key questions
Q: Why do authenticated routes often escape standard DAST coverage?
A: Authenticated routes usually depend on cookies, headers, or scripted actions that a basic crawler cannot infer from public pages.
Q: What can go wrong when custom scan discovery is too permissive?
A: The scanner can become a privileged execution path rather than a bounded test step.
Q: How should security teams test hidden application paths that crawlers miss?
A: Use multiple discovery sources.
Practitioner guidance
- Define discovery sources by route type Map which routes should come from crawling, HAR capture, seed paths, or custom commands, and assign each source to the application pattern it best represents.
- Control HAR files as sensitive test artefacts Store HAR captures with the same care as other test inputs because they can include cookies, headers, and authenticated request details.
- Restrict custom discovery commands Allow only approved commands and environments for custom scan discovery so pipeline execution cannot drift into arbitrary shell access or uncontrolled network calls.
Bottom line: Standard crawling still misses hidden and authenticated paths in modern applications, so DAST coverage depends on more than link following.
Glossary terms: Scan Discovery, HAR File, Seed Path, Custom Scan Discovery
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/08/2026 12:36 pm
Discovery breadth is now a governance problem, not just a scanner setting. When DAST relies only on link crawling, it inherits the false assumption that exposed application routes are easy to enumerate from a homepage. Hidden endpoints, authenticated workflows, and scripted flows invalidate that assumption. For practitioners, the key question is whether discovery reflects the real attack surface or just the easiest part of it.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should teams combine crawling, HAR files, and seed paths in DAST?
A: Yes, when they represent different parts of the application surface. Crawling covers discoverable links, HAR files capture real session behaviour, and seed paths ensure known hidden routes are tested. Combining them reduces blind spots, but only if teams own the inputs, update them as the app changes, and keep discovery logic under change control.
👉 Read our full editorial: Customized scan discovery changes how DAST reaches hidden paths