Will the scanner log into our website?

No. The current website workflow assesses the authorized public serving path and does not accept or use application credentials, session cookies, or authenticated customer flows.

Does it download response bodies?

The platform enforces bounded network reads and does not persist response bodies or raw scanner output. Trusted findings retain only sanitized, size-limited evidence.

Can it follow redirects?

Only bounded HTTP or HTTPS redirects are eligible. Every destination is freshly resolved, checked for public-safe addresses, and pinned before connection.

Is this a full web application penetration test?

No. It is repeatable external vulnerability scanning for supported public exposure conditions. Authenticated flows, business logic, source code, and human exploitation require separate testing.

Website vulnerability scanner

Turn public website exposure into clear remediation work

Check authorized websites for supported TLS, HTTPS, header, redirect, configuration, and policy-approved web exposure conditions without handing teams raw scanner noise.

Start free Talk to the team

Three assets free for 14 days. Ownership verification and explicit authorization are required before scanning.

Exact website scope

The submitted hostname, verified ownership source, authorization snapshot, and scan policy stay linked throughout execution.

Safe HTTP behavior

Only HTTP and HTTPS are allowed, redirects are revalidated, connections are pinned to validated addresses, and response size is bounded.

Remediation context

Findings include bounded evidence and actionable guidance, with lifecycle and retest history visible across the workspace.

How it works

From owned scope to a remediation queue

Every run starts from a verified target and an explicit policy—not an open-ended scanner instruction.

1
Verify the domain
Publish one apex `_vulnerabilityscan` TXT record where eligible, or use the bounded HTTPS verification method.
2
Authorize web checks
Review the exact host, Safe External policy, approved check categories, exclusions, and verification source.
3
Fix and verify
Use finding guidance, assign a disposition, and run an authorized follow-up scan to preserve the before-and-after trail.

Platform workflow

Useful security context without an oversized console

HTTPS and certificate posture

Review supported certificate, TLS, hostname, and redirect conditions from the public serving path.

Security headers

Identify supported missing or unsafe response-header configurations with bounded header-only evidence.

Redirect validation

Follow only bounded HTTP/HTTPS redirects after re-resolving and revalidating every destination.

Public technology signals

Where an approved profile supports it, use bounded fingerprints to select eligible non-destructive checks.

Web exposure findings

Policy-approved catalog checks can identify supported public misconfigurations or known exposure patterns without storing bodies.

Reports and retests

Connect website findings to scans, remediation notes, lifecycle events, exports, and clearly labeled reports.

What this does not replace

Clear boundaries make automated findings more useful and safer to operate.

The website profile is not authenticated application testing and does not log into customer, employee, administration, or API sessions.
It does not replace source-code review, SAST, dependency/SBOM analysis, business-logic testing, or a human web application penetration test.
WordPress, cloud-account, internal-network, and API-specific coverage must not be inferred unless a corresponding production profile explicitly supports it.
Coverage varies by authorized profile and reachable behavior; blocked, filtered, rate-limited, or failed checks remain visible rather than becoming a clean claim.

Questions

Know the boundary before you scan

Need to evaluate a specific use case? Talk to the team.

Know what is exposed.

Your first scan is one verified domain away

Three assets free for 14 days. No card required.

Start free