Skip to main content
VulnProScanby Dynamgenix IT Corp

How Vuln Pro Scan works

A detailed phase-by-phase breakdown of the authorized DAST scanning pipeline — from target authorization through active testing, finding analysis, and structured report delivery.

Phase 01

Target Authorization & Scope Definition

Every scan begins with explicit authorization. Vuln Pro Scan is a DAST tool designed exclusively for authorized testing — you confirm you own or have permission to scan the target before any traffic is sent.

Authorization confirmation

Before a scan begins, the platform records your authorization acknowledgment. This creates a clear audit trail that the scan was authorized by an authorized party for the submitted target.

Scope boundaries

The scan scope is bounded to the submitted host. The spider follows discovered links but stays within the same origin. Out-of-scope domains, third-party services, and CDN-hosted assets are excluded by default.

Staging vs. production guidance

Active testing generates real HTTP traffic including requests with injection payloads. Staging environments are recommended for initial assessments to avoid disruption to live users or backend systems.

Phase 02

Spider & Attack Surface Mapping

The scanner crawls the application to build a complete map of its attack surface: pages, forms, links, API endpoints, and input parameters. Surface mapping determines what gets tested in the active phase.

Link and form crawling

The spider follows href links, form actions, and redirects discovered in HTML responses. It builds a tree of reachable URLs within scope and records discovered form inputs, query parameters, and path variables.

API endpoint discovery

JSON and REST API endpoints returning structured data are identified during surface mapping. GraphQL endpoints are probed for schema introspection. Discovered API routes are added to the active testing queue.

Authenticated surface (Pro/Enterprise)

When running an authenticated scan, the spider follows links accessible only after login. This dramatically increases the attack surface coverage — most application logic and protected resources are only reachable after authentication.

Phase 03

Active Vulnerability Testing

Each discovered input and endpoint is exercised across the 12 security domains using OWASP-aligned test cases. This is where real payloads are sent and responses are analyzed for vulnerability evidence.

Injection testing

SQL injection, XSS, path traversal, open redirect, command injection, and SSTI payloads are submitted through all identified input vectors — form fields, query parameters, headers, JSON body fields, and URL path segments. Response analysis identifies error-based, reflected, and behavioral indicators of vulnerability.

Authentication and session testing

Login forms are evaluated for username enumeration, missing rate limiting, and account lockout. Session cookies are inspected for Secure, HttpOnly, and SameSite attributes. Token predictability and session fixation patterns are checked where applicable.

Security header and TLS evaluation

HTTP response headers are checked against a reference set of security headers (CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy). TLS configuration is evaluated for deprecated protocols, weak cipher suites, and HSTS preload readiness.

API and configuration checks

CORS policies are tested for overly permissive configurations. GraphQL introspection availability is verified. Unnecessary HTTP methods and exposed admin interfaces are flagged. API responses are examined for sensitive data exposure.

Phase 04

Finding Analysis & Deduplication

Raw test results are processed to group related alerts, remove noise, and produce a deduplicated finding set organized by vulnerability class and affected asset.

Grouping by class and location

Multiple alerts triggered by the same vulnerability type on the same endpoint are consolidated into a single finding. This reduces report volume while preserving the evidence of the highest-confidence instance.

False positive reduction

Results are analyzed against behavioral baselines established during surface mapping. Alerts with low confidence or ambiguous evidence are suppressed or flagged as Informational rather than inflating the High/Critical counts.

Evidence capture

For each finding, the HTTP request that triggered the alert and the response that confirmed it are captured as evidence. Developers can use this to reproduce and verify the finding without needing scanner access.

Phase 05

Risk Prioritization & Report Generation

The final finding set is classified by severity, organized by security category, and assembled into a structured report with remediation guidance aligned to each finding type.

Severity classification

Each finding is assigned a severity level (Critical, High, Medium, Low, Informational) based on the potential impact of exploitation, attacker access required, and the confidence of the detection. Severity context helps teams prioritize which findings to remediate first.

Category organization

Findings are grouped by OWASP-aligned security category — injection, authentication, authorization, session management, security headers, TLS, API security, and more. This supports batching remediation by engineering team or domain.

Remediation guidance

Each finding type includes targeted remediation guidance explaining how to address the root cause — not just a generic recommendation, but specific controls relevant to the technology and pattern detected.

Dashboard and export

Results are available in the dashboard for tracking, filtering, and trend analysis across scan runs. Reports can be exported for compliance evidence, developer ticketing workflows, or management review.

See it in action

Start with a limited demo scan preview, or sign in for the full scan console and dashboard.

More resources