GGateTest

Glossary

Dynamic Application Security Testing (DAST)

DAST tests a running application from the outside — sending real requests to find vulnerabilities that only appear at runtime, like broken authentication, missing security headers, and server misconfiguration.

Dynamic Application Security Testing treats the app as a black box. It drives a deployed instance with crafted HTTP requests, a headless browser, or a fuzzing harness, and watches how the system responds: does an unauthenticated request reach an admin route, does the login form leak which usernames exist, are security headers present, does a malformed payload trigger a 500 with a stack trace.

DAST's strength is that it sees the system as an attacker does — the real deployment, with its real configuration, middleware, and infrastructure. It finds whole categories of issue that source analysis structurally cannot: a reverse proxy that forwards an internal header, a cookie missing the Secure flag in production, a content-security-policy that was never applied.

The cost is that DAST needs something running and reachable, it lands later in the lifecycle, and a finding tells you the symptom (an exposed endpoint) without always pointing at the line of code responsible. Good pipelines run DAST against staging on every deploy and feed the results back to the team that owns the code.

How GateTest handles it

GateTest's live-scan modules are DAST: the headless-browser runtime-error capture, the visual-regression screenshot diff, the live crawler, and the API health probe. They observe how the deployed site responds; they do not send attack payloads — GateTest does not run penetration tests. They run where a browser and a target URL are available (the GitHub Action, a worker, or the URL-scan flow) and complement the static modules — the header, TLS and cookie scanners read your config and source rather than probing the deployed site.

Related modules: runtimeErrors, liveCrawler, apiHealth, visualRegression

Frequently asked questions

When should I run DAST instead of SAST?

Run both. Use SAST on every commit to catch code-level flaws early, and run DAST against a deployed staging environment to catch runtime and configuration issues that source analysis can't see. Neither replaces the other.

Does DAST need access to source code?

No. DAST tests a running application from the outside, so it works without source. That also means its findings describe symptoms rather than the exact responsible line, which is why teams correlate DAST results back to the owning code.