Customized scan discovery changes how DAST reaches hidden paths

At a glance

What this is: StackHawk describes configurable DAST scan discovery that reaches hidden or authenticated application paths through spidering, HAR files, seed paths, and custom commands.

Why it matters: It matters because security teams need broader application coverage without assuming a crawler alone can map real user paths, especially where authenticated routes and pipeline-driven test flows are involved.

Context

Application discovery is the step where a scanner learns which routes exist before active testing begins. In this case, the security gap is not lack of scanning, but incomplete visibility into paths that are unlinked, authenticated, or only reachable through scripted interactions. That matters to application security programmes because hidden paths often contain the exact logic and access boundaries defenders most need to test.

The identity angle is indirect but real: HAR-based discovery can capture authenticated routes, and custom discovery can replay developer-driven test flows that expose application behaviour behind login or session state. That makes route discovery a control problem as much as a tooling problem. If the scan cannot safely reproduce the path a user or test harness takes, the testing programme misses the attack surface it was meant to validate.

Key questions

Q: How should security teams test hidden application paths that crawlers miss?

A: Use multiple discovery sources. Crawling finds linked routes, HAR files reveal authenticated traffic, seed paths add known hidden endpoints, and custom discovery can replay real test workflows. The best approach is to treat these methods as complementary coverage inputs, then govern them so discovery remains repeatable, observable, and safe inside the pipeline.

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. HAR capture and custom discovery solve part of that gap by preserving the request context that proves the route exists. Without that context, the scanner sees only the unauthenticated shell of the application.

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. If arbitrary commands, broad environment access, or uncontrolled proxying are allowed, discovery may expose sensitive traffic or create new operational risk inside the pipeline. Governance has to cover both what is scanned and how the scan is triggered.

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.

Technical breakdown

How DAST discovery builds a site tree

DAST tools do not test a web application effectively until they know what to test. Spidering is the default discovery method here: the scanner starts from a base host, follows same-origin links, and adds discovered routes to an internal site tree for later active testing. That site tree is the scanner’s working map of exposed paths. The article also notes that passive checks can run while discovery is happening, which helps detect obvious issues early. This model works well for linked content, but it depends on visible navigation and reachable URLs, so hidden or script-driven routes remain easy to miss.

Practical implication: validate that your scanner’s discovery model matches your application’s actual routing pattern, not just its homepage links.

Why HAR files and seed paths matter for authenticated routes

HAR files and seed paths solve different discovery failures. HAR files record browser requests, headers, cookies, and response details, so they can expose authenticated or interaction-heavy routes that a crawler would never infer from static links. Seed paths do the opposite: they let teams explicitly tell the scanner about known routes, including unlinked or hidden endpoints. In practice, this shifts discovery from guessing to intent. The control challenge is that these inputs can contain sensitive session material or hand-curated route lists, so they expand coverage only when handled as governed test artefacts rather than ad hoc files.

Practical implication: govern HAR capture and seed path maintenance as part of test data handling, not as informal developer convenience.

What custom scan discovery changes about pipeline testing

Custom scan discovery turns DAST into a proxy for real workflow execution. Instead of only crawling a site, the scanner can intercept the HTTP traffic generated by tools such as API test suites or browser automation, then feed those requests into the scan tree. That makes it possible to test paths that only exist when code, browser state, and environment variables are orchestrated together. The risk is that the scanner now depends on the safety of the command being executed, the environment it runs in, and the secrets it can access. Discovery becomes closer to a controlled execution workflow than a passive inventory exercise.

Practical implication: treat custom discovery commands as privileged pipeline steps and restrict what they can execute and observe.

NHI Mgmt Group analysis

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.

Custom scan discovery is a workflow control, not a convenience feature. The moment a scanner can execute commands, capture proxy traffic, and ingest HAR files, the discovery process starts to overlap with pipeline trust, session handling, and test artefact governance. That makes route coverage dependent on how securely the organisation controls test execution, not only on the scanner itself. Teams should treat discovery inputs and execution paths as governed security assets.

Authenticated application paths need identity-aware testing discipline. The article’s strongest implication is that visibility into protected routes depends on session-aware evidence, not static inventory. That aligns with broader IAM thinking: if the scanner cannot safely replay the access path, the security programme cannot validate what that access path exposes. The practitioner conclusion is simple: discovery must be designed around how access actually works.

Hidden-path coverage exposes the limits of crawler-first security thinking. A scanner that can only follow links will systematically under-test modern applications that rely on API clients, automation, or browser-mediated state. The operational lesson is that testing coverage should be built from multiple discovery sources, then governed centrally so each source remains observable, repeatable, and safe to run.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Route discovery now sits inside application governance. Teams should stop treating DAST discovery as a one-time scanner configuration and start treating it as part of application route governance. If the test harness cannot represent authenticated and hidden paths, vulnerability testing is only partial. The operational priority is to align discovery methods with how the application actually serves users and automation.

Discovery coverage depends on the quality of test artefacts. HAR files, seed paths, and custom commands all broaden reach, but they also introduce artefacts that need versioning, review, and safe handling. That creates a control point for security and engineering teams: manage the discovery inputs with the same discipline as other pipeline assets so the scan tree remains trustworthy.

For practitioners

• 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.
• Seed known hidden routes deliberately Maintain seed paths for unlinked or difficult-to-reach endpoints so the scan tree includes business-critical routes that crawlers would otherwise miss.

Key takeaways

• Standard crawling still misses hidden and authenticated paths in modern applications, so DAST coverage depends on more than link following.
• HAR files, seed paths, and custom discovery each solve a different visibility gap, but they also turn discovery inputs into governed artefacts.
• The practical challenge is to expand scan reach without making pipeline execution, session capture, or route injection harder to control.

Key terms

• Scan Discovery: Scan discovery is the step where a security tool identifies which application routes, endpoints, or paths it should test. It determines coverage before active testing begins and is often the difference between finding real exposure and testing only a narrow slice of the application.
• HAR File: A HAR file is a browser-generated record of network activity that captures requests, responses, headers, cookies, and timings. Security teams use it to replay authenticated navigation or dynamic application flows so scans can reach paths that crawlers may miss.
• Seed Path: A seed path is an explicitly provided application route that a scanner should visit even if it cannot discover it automatically. It is a practical way to force coverage of hidden, internal, or unlinked endpoints that matter for testing and governance.
• Custom Scan Discovery: Custom scan discovery lets a security tool run a specified command and observe the traffic it generates. This is useful for reusing existing tests, but it also turns discovery into privileged automation that must be governed like any other pipeline workload.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect identity controls to broader security operations and governance.