Can you run DAST from your existing end-to-end tests?

Yes. Point your browser-based end-to-end tests at a scanning proxy and the scanner inspects every request the tests make, giving you passive findings with no extra scripting. Then replay chosen flows with active checks in a test environment, kept apart from the functional suite so failures stay clear.

The idea

Your QA suite already knows how to log in, click through checkout and fill forms. A crawler has to guess at all of that. If the test traffic flows through a scanner, the scanner sees real, valid sessions and realistic requests, which is exactly what it struggles to build alone.

The ZAP documentation describes its passive scanner as analyzing messages, such as HTTP and WebSocket, proxied through it. That means traffic from a test run is scanned as it passes, with no attack requests added.

What you get

Steps

1. Choose a stable test suite. Pick end-to-end tests that pass reliably on staging.
2. Run the scanner in proxy mode as part of the test job, in a container or a service.
3. Configure the test browser to send traffic through the proxy, and trust the proxy's certificate in the test environment only.
4. Run the suite. The proxy records the requests and runs passive checks.
5. Export the results and attach them to the build.
6. Use the discovered URLs as seeds for a separate active scan, so the active run reaches authenticated pages.
7. Set fail levels gradually, as you would for any new check.

Limits

• Coverage depends on the tests. Pages your tests never visit are never inspected.
• Passive only by default. Finding injection needs active requests, which belong in a separate run on disposable data.
• Proxy certificate handling can break a few tests. Fix it in the test setup, not in production.
• Test accounts are limited. Tests rarely cover permission differences between roles, so run flows as more than one role if you can.
• Slower tests. Proxying adds overhead. Keep the job separate from your fast unit tests.

Keep the active step separate

Running attack payloads through the same suite can corrupt data and make the tests flaky. Keep active scanning as its own job against a resettable environment. Use the E2E run to teach the scanner the site, then let the scanner attack on its own schedule.

What to measure

Count the number of distinct URLs and API operations the proxy saw, and compare with the list of routes in your app. The gap shows where your tests, and so your scans, do not reach.

A worked example

A team has 60 browser tests that log in, search, add items to a basket and check out on staging. They want scan coverage of authenticated pages without writing scan scripts.

1. Add a proxy service to the test job, running next to the test runner in the same network.
2. Set the browser's proxy to the service, and add the proxy's certificate to the test browser's trust store, in the test image only.
3. Run the suite. All 60 tests pass, now slightly slower.
4. Export the proxy's results. The passive checks report six alerts: two missing headers on the basket page, a cookie without a protective flag, an error message that shows a file path, and two information leaks in an API response.
5. Export the list of URLs seen. The proxy saw 94 distinct URLs and 31 API operations.
6. Compare with the route list. The app defines 140 routes. Forty-six were never visited by any test, including the account settings area and the support pages.
7. Act on the gap. The team adds three tests for account settings and loads the discovered URLs into a separate active scan as seeds.

The numbers are illustrative, but the exercise is useful because it measures how much of the app your tests touch. Often it is less than people assume.

Choosing where the proxy sits

For most teams the first option is cleanest, since each job gets a fresh proxy and a clean result.

Handling secrets in captured traffic

A proxy records everything, including login credentials and tokens used by the tests. Use test accounts only, and treat the output as sensitive. Delete captured sessions after the job and keep reports free of raw credentials.

Roles and permissions

Most suites log in as one user. Authorization problems appear only when you compare roles. Add a second set of tests for a lower-privilege user, or replay the captured requests as another user using a scanner feature for access control comparison. Even a simple check, such as requesting an admin page as a standard user, finds issues.

Moving from passive to active safely

After the first passive runs, take the discovered URLs and API operations and give them to an active scan in a separate job. Keep that job on a resettable environment. Do not run attack payloads through your functional tests, because failures will be hard to tell apart from real defects.

Measuring progress

Track three numbers over time: the share of routes your tests touch, the number of passive findings open, and the time to fix them. If route coverage rises and findings fall, the approach works. If tests slow down too much, split the security job from the fast suite.

Where Safeguard fits

End-to-end proxying covers behavior at runtime. For packages inside the app, Safeguard offers SBOM and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan.

Try it yourself

Click through it at your own pace, or open it full screen.

Think about which pages your own test suite would reveal to a scanner and which it would miss.

Quick check

Sources

• ZAP: Passive Scan

Last reviewed: 19 October 2026.