How to Scan a Website for Vulnerabilities (Step by Step)

TL;DR: Scanning a website for vulnerabilities is a six-step loop: define your scope and confirm you are authorized, choose unauthenticated or authenticated coverage (usually both), run a live scan, triage findings by real-world exploitability using EPSS and CISA KEV rather than raw severity counts, fix and rescan to verify, then put the whole thing on a schedule so the results stay true.

A vulnerability scan is easy to start and surprisingly easy to do badly. Point a tool at a domain and you will get findings; whether those findings are complete, prioritized sensibly, and acted on is another matter entirely. This guide walks through the full process the way we recommend running it, from the decision about what to scan all the way to continuous monitoring.

Step 1: What is in scope, and are you authorized to scan it?

Start with an honest inventory. A "website" is rarely one hostname: there is the apex domain, the www variant, an app subdomain, an API, a staging environment, and often a handful of forgotten deployments. Staging and legacy hosts are frequently the weakest links precisely because nobody thinks of them as part of the site. List everything you consider in scope, and decide explicitly whether staging environments are included.

Then confirm authorization. You may only scan domains and applications you own or have explicit written permission to test. Scanning a third party without authorization can violate computer-misuse laws and the target's terms of service, regardless of intent. OnScanner enforces this at the account level: targets you add must be ones you are authorized to test, and that requirement applies whether a scan is started from the dashboard, the API, or an AI agent.

Step 2: Should the scan be unauthenticated, authenticated, or both?

An unauthenticated scan looks at your site the way an anonymous attacker does: DNS and TLS posture, exposed services, technology fingerprints and their CVEs, security headers, email authentication, trackers. An authenticated scan logs in with test credentials and examines the surface only signed-in users can reach, where access-control and injection flaws in the application itself tend to live.

The practical rule: every target gets an unauthenticated scan, and anything with a login also gets an authenticated one. We break down the trade-offs fully in Authenticated vs Unauthenticated Scanning.

Step 3: How do you actually run the scan?

Add the target, then start the scan. From there the work happens in parallel: OnScanner runs specialist engines side by side rather than one monolithic crawler, covering OWASP Top 10 web checks, service and technology fingerprinting with CVE and CPE matching, TLS and DNS posture, WAF detection, email security (SPF, DKIM, DMARC), and privacy and tracker analysis across 40+ categories. Every scan runs live against the target at that moment; nothing is served from a cache, and each finding carries the evidence that produced it, so you can trace a result back to the exact response or header behind it.

One common worry deserves addressing: active checks. OnScanner's active exploitation probes are non-destructive by design, verifying in-band with read-only requests and never modifying target state, so confirming that a CVE is genuinely exploitable does not mean risking your production environment. The full detection approach, including how those probes stay safe, is documented in the methodology.

Step 4: How do you triage the findings?

This is the step most teams get wrong. Sorting by CVSS score alone, or worse by raw finding count, buries the issues that actually matter under ones that merely look severe. Modern triage uses exploitability signals alongside severity:

Work the table from the top. Confirmed-exploitable and KEV-listed findings come first because working exploits already exist for them. High-EPSS findings come next, then the remaining criticals and highs. Mediums and lows are best batched into scheduled hardening work rather than treated as emergencies.

Two nuances save enormous amounts of wasted effort. First, patch status: Linux distributions backport security fixes without changing the upstream version number, so a component that looks outdated may already be fixed. A scanner that evaluates patch status against distribution advisories keeps you from chasing non-issues. Second, end-of-life detection: when a product no longer receives security updates at all, patching individual CVEs is a treadmill, and the real remediation is an upgrade plan.

Step 5: How do you fix and verify the fix?

Remediate the priority findings, then rescan the same target. Because every scan runs live, the rescan reflects the current state of your infrastructure: a fixed finding disappears because it is actually gone, not because it aged out of a stale report. Compare the two reports, confirm the intended findings are resolved, and watch for anything new the fix may have introduced. Keep the before-and-after pair; it is useful evidence for audits, customers, and your own change history.

Step 6: How do you keep the results from going stale?

A scan is a statement about one moment. Your site changes with every deployment, certificate renewal, and DNS migration, and the threat landscape changes even when your site does not: new CVEs are published against software you have not touched, and existing CVEs get added to the KEV catalog overnight. Schedule recurring scans so drift is caught automatically instead of discovered during an incident. We look at why observation freshness changes the value of a finding in Live Scans vs Cached Results.

Cost is not the barrier it used to be: OnScanner's Starter tier is free, and the Professional plan is $60 per month, so a scan-after-every-deploy habit is affordable well before a security budget exists.

When do you need more than a scanner?

Scanners are unbeatable at breadth, repetition, and speed: known vulnerabilities, misconfigurations, exposed services, and drift over time. They are structurally weak at business-logic flaws, chained multi-step attacks, and judgment calls about authorization design, because those require understanding what the application is supposed to do. For high-value applications, pre-launch reviews, and compliance-driven assessments, pair continuous scanning with manual penetration testing by human experts. The scanner keeps you covered between engagements; the humans go where automation cannot.

Frequently asked questions

How often should you scan a website for vulnerabilities?

Scan after every meaningful deployment and on a fixed recurring schedule, whichever comes first. Deployments change your surface directly, while new CVE publications and KEV additions change your risk even when the site itself is untouched. Fast-moving applications handling sensitive data warrant a tighter cadence than static brochure sites, but no site is safe with a once-a-year assessment.

Can a vulnerability scan break your website?

A carelessly built scanner can, which is why the design of active checks matters. OnScanner's exploitation probes are non-destructive: they verify in-band using read-only requests and never write, delete, or modify target state. Standard operational hygiene still applies, of course: tell your team a scan is running, and start with staging if you are unsure how a fragile legacy system will behave.

What is the difference between a vulnerability scan and a penetration test?

A scan is automated, repeatable, and broad: it finds known vulnerabilities, misconfigurations, and exposure across your whole surface in minutes and can run continuously. A penetration test is human-led and deep: an expert chains findings, probes business logic, and pursues goals automation cannot reason about. They complement rather than replace each other, so mature programs scan continuously and test periodically.