Dynamic Testing is ZeroPath’s Dynamic Application Security Testing (DAST) capability for running applications. It can be deployed in three ways: discover vulnerabilities in live applications, confirm which static findings are exploitable at runtime, and verify that fixes resolve the issue after merge.Documentation Index
Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt
Use this file to discover all available pages before exploring further.
The dashboard uses Runtime Validation for the issue-specific DAST
workflow: routes, tabs, run pages, and issue evidence sections still use that
name. Runtime Validation is one mode of ZeroPath Dynamic Testing.
What It Does
Dynamic Testing exercises a configured running target with finding context, application profile inputs, and encrypted runtime credentials. The goal is to produce evidence from the live application rather than relying only on static analysis.| Mode | Use case |
|---|---|
| Live discovery | Run dynamic tests against production or staging APIs to find runtime-only vulnerabilities such as prompt injection and IDOR. |
| Runtime validation | Start from a completed SAST finding and confirm, disconfirm, or explain exploitability against the deployed application. |
| Post-merge verification | Reuse the dynamic profile after a patch lands to verify the vulnerable behavior no longer reproduces. |
| Result | Meaning |
|---|---|
| Queued | The issue is part of the run but has not reached a final verdict yet. |
| Confirmed | ZeroPath observed runtime evidence that the issue is exploitable. |
| Disconfirmed | ZeroPath could not exploit the issue in the configured runtime environment. |
| Unable | Validation could not reach a trustworthy verdict, such as when required runtime state was unavailable or the application was unreachable. |
Vulnerability Classes
Dynamic tests can target runtime behaviors that are difficult to prove from source alone:- Prompt injection - tests whether AI-powered features execute injected instructions by manipulating inputs across user-facing and backend prompts. Findings show the injection path and model response.
- IDOR - exercises object identifiers across authenticated roles to prove when users can access resources they do not own.
- Vulnerability chaining - combines multiple runtime behaviors to show how smaller weaknesses become a practical attack path.
- Out-of-band (OOB) vulnerabilities - detects blind SSRF, blind XXE, blind SQL injection, DNS exfiltration, and other vulnerabilities where the exploited behavior is not visible in the HTTP response. The validation agent generates unique callback URLs on
oob.0path.aiand monitors for outbound requests from the target application, proving that the injected payload triggered a real server-side request.
Out-of-Band Testing and Network Requirements
OOB testing usesoob.0path.ai as the default callback server. The validation agent injects unique URLs under this domain into the target application and monitors for DNS lookups, HTTP requests, and other protocol interactions that prove the vulnerability is exploitable.
If your target application runs behind a firewall or egress filter, you may need to whitelist *.oob.0path.ai (DNS and HTTPS) so the target can reach the callback server. Without this, OOB tests will return no interactions even if the vulnerability is real.
Prerequisites
Dynamic Testing requires:- A deployed application reachable by the validation worker.
- A Runtime Validation application profile for the detected application.
- All required profile inputs saved, such as target URL and generated authentication fields.
- For issue-specific validation, a completed full scan with eligible SAST findings.
Running Runtime Validation
- Full Application
- Selected Issue
Use a full-application run when you want to validate every eligible issue for an application profile.
Reviewing Results
The repository Runtime Validation tab shows recent validation runs. Selecting a run opens a dedicated run page with result tabs:- Queued - issues still waiting for runtime validation.
- Confirmed - issues proven exploitable at runtime.
- Disconfirmed - issues that did not reproduce in the configured runtime environment.
- Unable - issues where validation could not produce a reliable verdict.
Issue-Level Evidence
When a finding has Runtime Validation output, the issue modal and full issue view include a collapsed Runtime Validation section below the exploit walkthrough. It summarizes:- The latest verdict and run status.
- What ZeroPath attempted during runtime testing.
- Evidence observed during the attempt.
- Why the finding was confirmed, disconfirmed, or marked unable.
- A link to the dedicated run page for broader run context.
Operational Notes
- Full-application runs are blocked while another active run exists for the same scan and application profile.
- Selected-issue runs are blocked only when a full-application run is active or when another active selected-issue run already targets the same finding.
- Dynamic Testing depends on the configured deployed target, so a failure to reach the application should be treated as an environment or profile problem before treating the finding as disconfirmed.
- For repositories with many scans, use the run list and result tabs instead of scanning issue-by-issue from the main issues table.