Is this a full penetration test?

No. It's an automated audit of the real traffic your app produced during exploration. It reliably catches common, high-value classes of issues — auth and credential exposure, missing authorization, over-exposed data, leaked errors, transport and cookie handling, version disclosure, cacheability and missing rate limiting — but it does not chain exploits or probe business logic the way a skilled human does. It complements a manual pentest; it doesn't replace one.

Do I have to configure or point a scanner at my app?

No. The audit runs on the HAR already captured while Validate.QA explored your app, so there's nothing extra to deploy, point at a target, or wire into CI. If no traffic exists yet, you can trigger a capture run that drives a real browser to record it first.

Does it need authenticated traffic to be useful?

That's where it's strongest. Because the capture includes the session established after the agent logs in, the audit sees the authenticated endpoints external scanners never reach — which is exactly where data exposure and authorization issues tend to hide.

What categories of issues does it cover?

At a high level: authentication and credential exposure, sensitive data and PII in responses, missing or weak authorization, over-fetching, leaked server errors, transport and cookie security, technology-version disclosure, cacheability of sensitive responses, and missing rate limiting on authentication endpoints. Reflected input and privilege-control fields in write requests are also considered.

How do findings avoid being noisy false positives?

The audit reads the discovery context, so expected outcomes — like a 401 during a deliberate wrong-password test — aren't flagged. Higher-value candidates can additionally be confirmed against the running app with scoped requests before they're presented, and each finding is labelled as confirmed, a false positive, or an unverified observation.

How do findings become regression checks?

Each finding is tracked with a lifecycle and de-duplicated by endpoint and category across runs. Issues that disappear auto-resolve and recurring ones re-open, so the report stays current. The ones that matter can be turned into checks, so a reintroduced issue is caught automatically on the next run instead of being rediscovered manually.

Security testing

Because Validate.QA already captures full network traffic while it explores your app, it can audit what your endpoints actually send and receive — including authenticated flows. Security becomes a by-product of the same run that writes your tests, with no separate scanner to configure.

Mechanism: Multi-category security audit over the captured HAR, with optional live verification of findings.

The problem: Security testing usually lives in a separate tool with its own setup, so it gets deferred and quietly skipped in CI. Scanners that crawl from the outside never see authenticated traffic, so issues that only surface inside real logged-in flows go unnoticed. DAST tools probe by firing payloads at your app; they rarely have ground-truth about what each response should contain, so over-exposed data and broken object-level authorization slip through. Even when a finding is reported once, it almost never becomes a durable check — so the same regression comes back on the next deploy.

Reuse the captured traffic — The audit runs on the same full-fidelity HAR that Validate.QA already records while exploring your app — real requests and responses, including the authenticated calls made after the agent logs in. Nothing extra is pointed at your app; the traffic the tests were written from is the same traffic the audit inspects.

Group and normalize by page and endpoint — Requests are grouped by the page where they were observed and collapsed by method, path, status and auth state. The audit understands the discovery context — negative tests with intentionally wrong credentials, the happy path, and the authenticated session that follows login — so expected failures during negative testing aren't mistaken for vulnerabilities.

Analyze across security categories — Each endpoint is examined against a broad set of categories: authentication and credential exposure, sensitive data and PII in responses, missing or misapplied authorization, over-fetching, leaked server errors, transport and cookie handling, technology-version disclosure, cacheability of sensitive responses, and missing rate limiting on auth endpoints. Token claims, reflected input and privilege-control fields in write requests are weighed in context rather than by blunt pattern matching.

Verify the candidates that can be verified — Higher-value candidate findings can be confirmed against the running app with carefully scoped, read-oriented requests that reuse the captured session. A finding is marked confirmed, dismissed as a false positive, or left as an unverified observation — so the report leads with issues that have been demonstrated, not just inferred from traffic shape.

Surface a prioritized report — Findings are persisted with a severity (critical, high, medium, low, info), a category, the affected endpoint and the page where it appeared. They're available as a readable report and through the assistant and MCP tools, so you can list and triage them without leaving your workflow.

Track over time and turn into regressions — Findings carry a lifecycle: open, acknowledged, or marked a false positive. Issues that stop appearing in a later audit auto-resolve, and recurring ones are re-opened — so the report reflects today's reality. The important findings can be encoded as checks, so the next time the issue reappears it's caught as a regression rather than rediscovered by hand.

Open Security testing · Get Started Free