DAST for Web Applications: Comparing Burp, Invicti and Acunetix

Why compare DAST on your own test environment

DAST for web applications is chosen not for a "pretty report," but to answer practical questions: what real risk the product has, what to show an auditor, and how to avoid blocking releases with constant manual checks.

Testing on your own environment shifts the conversation from "which tool is more popular" to "which tool delivers the needed results on our app." Some teams care more about speed and stable CI runs, others about deep checks in the user account, and others about a low false-positive rate so developers keep trusting reports.

Demos and marketing tests rarely reflect reality. Demos usually lack complex authentication, non-standard APIs, real rate limits, and forms/errors are made "friendly" for the scanner. On a live product one tool may easily "lose" half the functionality behind login, another may be blocked by a captcha or redirects, and a third may find many issues but a large share of them can't be confirmed.

If you compare "quickly," the conclusion will almost certainly be wrong. The usual factors that break comparability are:

• tools run with different settings and time windows and then someone tries to compare raw numbers;
• authorized areas are only partially tested, and this is not visible in the report;
• false positives are mixed with real bugs, making the assessment subjective;
• the test environment behaves differently (different build, roles, data), so the experiment stops being an experiment.

A simple guideline: imagine a portal with a public area and a personal account that has "user" and "operator" roles. The business needs to know whether the scanner will find vulnerabilities where personal data and payments are processed and how much time will be needed to triage results after each run.

For organizations with compliance or public procurement requirements it's especially important to fix the comparison methodology in advance. Then conclusions can be defended before internal control and external auditors, instead of arguing about "why today's report is different."

What to compare: coverage, authorization and false positives

When choosing a DAST, it's not just "who found more" or "who scans faster." In practice the tool must (1) reach the right parts of the site, (2) remain functional after login, and (3) deliver findings you can trust.

Coverage: what was actually tested

Coverage answers which parts of the application the scanner actually visited and tried to test. "Visited" matters more than "could theoretically visit." One tool may open a page but not submit a form. Another may get lost in endless parameters and miss an important section.

To make the comparison fair, agree in advance what counts as coverage and how to verify it. Typically keep at least:

• how many unique pages and endpoints were requested;
• how many forms and actions (search, create, upload) were submitted;
• which API methods were actually called (GET, POST, etc.);
• whether the scanner reached "deep" screens rather than stopping at the main page and login.

Example: the account contains "Profile," "Payments," and "Requests." If a report looks convincing but server logs show no calls to the "Requests" section, coverage has effectively failed.

Authorization: where the scanner must log in and what it does afterwards

Testing authorized zones often decides the comparison outcome. It's important not only to be able to log in, but to maintain the session, refresh tokens and understand that a new set of pages and actions appear after authentication.

Define boundaries up front: which roles to test (user, operator, admin), which flows are critical (password change, checkout, data management). Separately define what success looks like. For example: the scanner reached a page showing a contract number and was able to perform the "create request" action.

False positives: how to separate noise from risk

False positives sound scary but are unconfirmed. They waste time and quickly destroy trust in the tool.

It's better to evaluate the share of confirmed issues rather than the raw count. For some findings agree in advance a verification method: repeat the request, compare responses before and after changing a parameter, reproduce the issue in a browser.

Results are strongly influenced by lab constraints, so record those as well:

• WAF or protection rules that block "suspicious" requests;
• rate limits and IP bans after repeated requests;
• CAPTCHA and additional login checks;
• unstable test data (record already exists, object deleted);
• random environment errors that break the scanner's route.

If these conditions aren't described, Burp Suite Enterprise, Invicti and Acunetix will appear incomparable even though the problem lies in the environment, not the DAST itself.

Preparing the test environment and reference checks

A DAST comparison only makes sense under identical conditions. The most common cause of "strange" results is different app versions, different data or transient UI elements that let one scanner go further while another fails.

Start by fixing the same build and configuration: identical feature flags, cache settings, security headers, integrations (unless they can be disabled). If the test environment is near staging, ensure the release doesn't change during runs. Otherwise you'll compare two app states, not Burp Suite Enterprise, Invicti and Acunetix.

Next prepare data and access. You need test accounts with different roles to correctly scan protected areas. These accounts should be predictable: the same permissions, filled profile, stable activity history, and no mandatory initial password change or other steps that break automation.

Then agree what must be found. This is your reference: a small set of vulnerabilities or test targets you can confirm manually. A practical reference set:

• 5–10 known issues from the backlog (for example, previously fixed issues reproducible on the test) or deliberately injected test points;
• 2–3 access control scenarios (e.g., a user trying to open an admin section);
• 2–3 input locations where it is safe to test injections and XSS.

Remove random factors: A/B tests, dynamic banners, personal recommendations, flaky redirects, and restrictions that cut traffic differently (rate limit, captcha). Otherwise one scanner will start receiving 403 responses or unexpected redirects and coverage becomes incomparable.

Finally, enable logging on the application and infrastructure: access logs, error logs, audit events, and request tracing with correlation ids. Then every finding can be verified: was the request made, what parameter went out, what response returned, and is this a vulnerability or a false positive.

Unified scanning conditions (unauthenticated)

Start by normalizing the simplest mode: scanning without login. This checks basic crawling and vulnerability discovery capabilities without mixing results with login/session settings.

Fix the start point and scope: what to scan (main domain, test subdomains, base paths like /, /api, /swagger), and what to exclude (admin panels, external services, placeholder pages). If the app has multiple hosts, approve the list in advance: only in-scope hosts count in results.

Then set identical limits so no tool gets an unfair advantage:

• time budget for the scan and identical launch windows;
• maximum crawl depth and unique URL limits;
• request rate (RPS) and concurrency;
• timeouts, response size limits and a unified retry policy for network errors.

Also agree on details that seem minor but change coverage: how redirects are handled (always or only within the domain), whether cookies are allowed, which headers to send (Accept-Language, X-Forwarded-For, custom headers), which User-Agent to use. If one tool acts like a "mobile" client and another like "desktop," you may get different pages and findings.

Decide what to keep as raw output. Besides the report, save request/response logs, the list of discovered URLs and the crawl map. When a disputed finding (or its absence) appears, these artifacts explain why: the tool didn't reach the page, got a 403, got stuck in a redirect or didn't submit an action.

Scanning authorized zones: step-by-step setup

Protected areas usually contain more logic and data than public pages. This is where DAST most often breaks: the tool loses the session, gets redirected to login, or scans the wrong role. To compare Burp Suite Enterprise, Invicti and Acunetix fairly, make authorization setup identical and record it.

1) Choose the login method

Identify how the app actually authenticates users. The test should resemble production as much as possible.

Common methods are form login (username/password), SSO, OAuth2, header-based login (via proxy), or pre-issued cookies. The important thing is that the method doesn't require manual steps (captcha, SMS confirmation). If such steps exist, create a separate test login method for the lab.

2) Ensure a stable session

Decide how the scanner will keep authorization during a long run. Sessions break due to timeouts, token refresh behavior or forced logout on parallel sessions.

Check three things: how tokens are refreshed, what happens on expiration, and whether there are limits on active sessions. On the test environment it's often reasonable to increase timeouts; otherwise you'll compare "who holds the cookie longer."

3) Limit areas and roles

Define scope in advance to avoid mixing results. For example, scan only the personal account under /cabinet or only functions of a specific role. It's more practical to run a separate scan for each role using distinct credentials.

Minimum settings to record for each tool:

• account and role;
• login/start URLs for crawling;
• scope rules (what's included and excluded);
• rate and concurrency limits;
• behavior on logout (stop the scan or re-authenticate).

4) Verify authorization with a control URL

Pick one control address that is definitely available only after login, with a clear success indicator. For example, a profile page showing the username or a balance section that shows a login form to guests.

Check not only HTTP 200 but also expected content. Otherwise a scanner may receive the login page (HTTP 200) and assume it is "inside."

5) Run short tests, then a full scan

First run 1–2 short tests on a narrow area to ensure transitions go to the right pages and the control URL consistently confirms authentication. Only then run a full scan and save the settings as a reference so Burp Suite Enterprise, Invicti and Acunetix can reproduce them in repeated comparisons.

How to assess coverage: what the tool really traversed

When comparing DASTs it's important to look beyond the number of vulnerabilities and see how fully the scanner actually "saw" the app. Otherwise one tool will seem stronger simply because it reached more pages and functions.

Coverage is confirmed visits and interaction attempts. Look at what was actually requested and processed, not just what was in the target list.

What to count as coverage in practice

Collect metrics from the scanners' reports and, where possible, from server logs (to confirm requests reached the app). Useful things to record:

• unique URLs and methods: how many different pages and endpoints were requested, including GET/POST/PUT/DELETE;
• parameters and variations: which query/path/body parameters appeared and how many distinct values were tried (especially for filters, IDs, search);
• forms: which forms were submitted, which fields were filled, and whether "edge" values were attempted;
• APIs and non-HTML: whether JSON, GraphQL, file uploads, document downloads and other content types were covered;
• roles and sections: which parts of the app were reached per role.

Compare by the same "units", for example the number of unique combinations (URL + method + parameter set). Raw page counts in reports can be misleading.

Reconcile with an "app map": what was missed and why

Create a short app map as a reference: list key sections, important URLs, main forms and API endpoints (from docs, Swagger/OpenAPI, frontend routes or menu structure). Then mark which were not reached.

If an area is uncovered, the reason usually belongs to a familiar set:

• navigation only via complex JavaScript (scanner didn't execute JS or failed to do so);
• specific actions required: master form, multi-step process, button confirmations;
• access filters: redirects to login, expiring sessions, CSRF, IP restrictions;
• missing "correct" data: section is empty and links don't appear without test records;
• crawler settings: path exclusions, depth limits, timeouts, too strict crawling rules.

Example: a payment history appears only after selecting a date range. One scanner may get stuck on the empty screen while another submits a date form and retrieves operations. The report then looks like "the first found nothing," but in fact it had lower coverage.

This approach makes comparing Burp Suite Enterprise, Invicti and Acunetix fair: you can see who actually traversed more routes and actions, and who simply didn't reach important parts.

How to measure false positives and confirm findings

Comparing raw reports from Burp Suite Enterprise, Invicti and Acunetix is pointless: different engines describe risk differently and often produce duplicates. To properly assess false positives on a test environment, predefine confirmation rules and a counting method.

Start with a simple classification along two axes: severity (Critical/High/Medium/Low/Info) and class (XSS, SQLi, SSRF, configuration issues, headers). This quickly shows where a tool generates more noise. False positives often concentrate in configuration issues and suspicious reflections, not in real injections.

Then fix what counts as proof of a vulnerability. A realistic minimal set of artifacts on a test lab:

• a snapshot of the request and response showing the trigger (e.g., reflected payload for XSS or a characteristic error for SQLi);
• repeatable reproduction of the same request 2–3 times;
• a sign of server impact: an entry in application logs, a state change, object creation or data modification;
• for SSRF-like classes — confirmation of the network call (proxy/DNS logs or a record on a test service);
• for configuration issues — checking the absence/presence of a header across multiple endpoints.

Separate out categories of "noise" or the comparison will collapse into arguments. Typical noise sources: timeouts and connection drops, unstable responses (cache, load balancer, different versions of a page), WAF blocks, checks triggered by redirects to login.

To make the comparison numeric, keep a simple table: finding, type, severity, confirmed/unconfirmed, reason for rejection, artifact (file/screenshot). Then compute the same metrics for all tools:

• confirmed share: confirmed / total;
• false share: false / total (false = "not confirmed" by rules);
• unsure share: when data is insufficient due to environment instability;
• number of unique findings excluding duplicates;
• time spent on manual verification of 10 findings (indicator of "noise cost").

Deduplicate findings, otherwise results will be inflated. The same reflected XSS can appear on 12 URLs for one root cause, and the same configuration issue may repeat across pages. Group by root cause (endpoint + parameter + class) and count "unique" issues.

Example: a scanner reports SQLi on search because it saw a 500 and the word "SQL" in HTML. By your rules this is not proof. You reproduce the request several times, check logs and see the 500 was caused by an external service timeout. That finding goes into "false" with reason "instability/timeout." This fairly reflects the tool's signal quality in your conditions.

Common mistakes when comparing Burp Suite Enterprise, Invicti and Acunetix

The main reason DAST comparisons differ from reality is simple: tools test different things. Even a small difference in build, data or settings makes the numbers incomparable.

Typical mistakes:

• changing the application during the test (different branch, config, data, enabling/disabling WAF);
• not fixing run boundaries: time limit, request speed, thread count, exclusions, crawl depth;
• counting only the number of vulnerabilities without checking coverage and confirmation quality;
• assuming the authenticated zone was tested while the scanner remained a guest (reports lack account pages, logs show many redirects to /login or 401/403 responses);
• postponing manual validation and then arguing about disputed reports for weeks.

A good habit is a short comparison protocol: which app build, which test accounts, run limits, exclusions and success criteria. Then results from Burp Suite Enterprise, Invicti and Acunetix are not just different numbers but understandable conclusions.

Example: you test a portal with a personal account. If one tool logged in as a "user" and only saw the profile, while another logged in as an "operator" and accessed requests and internal forms, comparing counts is meaningless. First align roles and routes, then discuss findings quality.

Example scenario: portal with a personal account and multiple roles

Imagine a corporate portal: public section (news, contacts, service catalog) and a personal account where users submit requests and pay for services. Such a bench is good for comparing DAST by what it finds in protected zones, not just "scanner speed."

The account has three roles, each with its own pages and actions:

• guest: sees public pages and can open the registration form;
• user: creates requests, edits profile, completes payments;
• admin: views request lists, changes statuses, exports reports.

The comparison goal is simple: determine whether a tool can traverse key paths in the account and correctly test forms (request, profile, payment), not just "spray" the homepage.

There are constraints that often break fair comparison. The lab has rate limits (after N requests per minute a 429 is returned), parts of the UI render with JavaScript, and sessions live 15 minutes. Any scanner that can't maintain authorization, re-login, or run scripted scenarios will struggle.

To keep comparisons equal, set common rules: the same set of accounts for all tools, identical time windows (e.g., 2 hours per user role and 2 hours per admin role), and a unified list of exclusions. Exclude pages that will certainly generate noise or are out of scope: logout, pages with test data, health endpoints, heavy exports that could destabilize the lab.

Decide how you will accept results. It's useful to evaluate three practical indicators rather than raw counts:

• confirmation: how many findings can be quickly reproduced and proven (important in payments and requests);
• coverage: did the scanner complete key steps (login, create request, start payment, view history);
• effort: how much time is spent on configuring auth, triaging false positives and re-running due to expired sessions.

If one tool "sees" the account but 70% of results are unconfirmed while another finds fewer issues but almost all are reproducible and cover payments and request statuses, the latter will often be more useful in daily work.

Quick checklist and next steps

Treat DAST comparison as a small experiment: same build, same rules, clear metrics. Then results will help make decisions instead of just showing "what happened."

Before starting, record conditions in one document:

• the same test build for all runs and enabled logging (requests, errors, auth events);
• roles and test accounts (guest, user, admin) without steps that break automation (2FA/captcha, mandatory password change);
• a control set of URLs and actions: 10–20 key pages and forms that should be traversed;
• limits: scan duration, crawl depth, request rate, launch windows;
• where to look for scan traces: app logs, WAF/proxy logs, auth journals.

After a run don't just count "vulnerabilities." First verify what the tool actually did:

• reconcile coverage: which sections were visited, which forms submitted, where the crawl stopped;
• split findings into confirmed and unconfirmed and note the verification method;
• remove duplicates (by root cause, not by report line count);
• record reasons for misses: redirects, CSRF, captcha, SPA navigation, environment instability, rate limits;
• save artifacts: scanner configs, versions, run times, raw request logs.

Summarize results as metric tables: coverage (how many control items reached), scan time, confirmed vulnerabilities by severity, false positive rate, and list of misses with reasons. Add 5–10 short confirmed examples in the format "request - response - why this is a vulnerability." These examples usually convince stakeholders faster than hundreds of report lines.

A typical rollout: pilot on one application and team, then expand to 3–5 apps, and only then formalize a regimen (when to run, who triages, who confirms, SLA for fixes).

If you need a dedicated lab for regular tests, it's sensible to host it on separate servers and workstations so scans are stable and reproducible. For infrastructure and integration tasks GSE.kz (gse.kz) experience can be useful as a manufacturer and integrator, especially when it is important to build a reliable environment and support for continuous testing.