Website Vulnerability Scanner: What It Finds and Misses

What a website vulnerability scanner finds and misses

An automated scanner crawls your pages, sends requests and compares the responses with patterns of known problems. A passive scan only examines normal traffic, which ZAP's documentation calls safe. An active scan sends attack-style requests, and ZAP warns to use it only on applications you have permission to test.

Scanners are good at spotting:

Software with known vulnerabilities, such as an old content management system, plugin or JavaScript library.
Missing security headers and weak cookie settings.
Expired certificates and outdated TLS versions.
Exposed backups, directory listings and admin logins.
Some injection and cross-site scripting patterns in forms and parameters.

They also miss a lot. NIST's testing guide, SP 800-115, notes that scanners produce many false positives, miss real issues, depend on current signatures and need an expert to interpret the results. Expect gaps in:

Business logic: applying a coupon twice looks normal to a scanner.
Access between users: a scanner cannot know that one customer should not see another customer's order.
Pages behind a login unless you configure a test account, and multi-step workflows.
Chained weaknesses that are minor alone but serious together, and APIs or subdomains nothing links to.

Scanner vs. website penetration testing vs. security assessment

These terms are often mixed up, and a quote for one may deliver another.

Vulnerability scan: automated, fast and repeatable. It lists likely known issues across a site, and a person still has to confirm them.
Penetration test: NIST describes it as testing in which assessors mimic real-world attacks to find ways around a system's security. In website penetration testing, a skilled tester combines tools with manual work, chains weaknesses and shows what an attacker could actually reach, within a set scope and time, often following the OWASP Web Security Testing Guide.
Security assessment: a broader review that can combine scanning, configuration review, testing and interviews into a prioritized plan.

A practical pattern: scan regularly, commission a penetration test before a major launch or when a contract requires one, and use an assessment for the whole picture.

Get written permission and set the scope first

Only scan sites you own or have written permission to test. An active scan can slow a site, submit forms or create junk records. In the U.S., the federal Computer Fraud and Abuse Act makes accessing a computer without authorization a crime and allows civil lawsuits in some cases, and state computer crime laws differ. Whether a given scan crosses the line depends on the facts and the jurisdiction; this is not legal advice.

NIST SP 800-115 recommends a written assessment plan. Record at least:

The exact domains, subdomains and IP addresses in scope, and what is excluded.
Who authorized the work, and when it may run.
Allowed techniques: passive only, active scanning or manual testing, with denial-of-service tests turned off.
How sensitive data found during testing will be handled, and who to call if something breaks.
Third parties. NIST notes that the owner of another network usually must also consent in writing, so check your hosting provider's testing policy and exclude payment pages and other services you do not own.

If you notice a problem on a site you do not own, stop testing and report it through the owner's vulnerability disclosure policy or the contact in its security.txt file, usually at /.well-known/security.txt.

Common findings in a website security scan

The OWASP Top 10 is the standard awareness list of the most critical web application risks. Its 2025 edition starts with Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures and Injection. Typical scan results include:

Outdated software: a content management system, plugin, theme or library with a known vulnerability. CISA notes that many updates exist to fix security risks; patch, or remove what you no longer use.
Misconfiguration: default pages, directory listings, detailed error messages or exposed admin panels.
TLS problems: expired or mismatched certificates and old protocol versions. NIST's TLS guidelines require U.S. government servers to support TLS 1.2 and TLS 1.3, a sensible benchmark for any site.
Missing headers: the OWASP HTTP Headers Cheat Sheet covers Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options and Referrer-Policy, and advises removing headers such as X-Powered-By that reveal software details.
Injection and cross-site scripting: input that reaches a database query or a page without proper handling.
Session issues: cookies without the Secure or HttpOnly flags, or sessions that never expire.

Free website vulnerability scanner options

Each free option still needs someone to set it up carefully and read the results.

ZAP: the ZAP project offers a free, open-source web app scanner. Its baseline scan crawls a site for about a minute and reports passive findings without performing actual attacks.
OWASP's tool list: the Vulnerability Scanning Tools page lists open-source, free and commercial scanners; OWASP states that a listing is not an endorsement.
Mozilla HTTP Observatory: the HTTP Observatory assesses a site's HTTP headers and other key security settings.
CISA Cyber Hygiene: CISA's Vulnerability Scanning and Web Application Scanning services are available at no cost to U.S. federal, state, local, tribal and territorial governments and to public and private critical infrastructure organizations.

How to read scan results and decide what to fix first

Confirm the finding. Check the reported version, reproduce the issue on a test copy if you can, and record why any false positive was dismissed.
Treat severity as a starting point. Many reports use CVSS scores from FIRST, now at version 4.0, which reflect severity. NIST advises assessors to judge the actual risk themselves rather than simply accept the scanner's rating.
Check for active exploitation. A CVE listed in CISA's Known Exploited Vulnerabilities catalog has been exploited in the wild, and CISA recommends the catalog as an input to prioritization.
Weigh exposure and data. A flaw on a public login or checkout page outranks one on a static brochure page.
Group by root cause. One outdated plugin can produce a dozen findings.
Assign an owner and a date for each fix, then rescan to confirm it worked.

How often to run a website security scan

There is no single schedule for every site. NIST notes that an assessment is a snapshot in time and that frequency is often driven by compliance requirements. A reasonable baseline for a small site:

After every significant change, such as a new plugin, a platform update or a hosting move.
On a regular schedule, such as monthly, plus a passive baseline scan after each release.
A fuller authenticated scan or a penetration test at least once a year and before major launches.
If you accept card payments, PCI DSS Requirement 11.3.2 calls for passing external scans by an Approved Scanning Vendor at least once every three months, according to the PCI Security Standards Council. Ask your payment provider what applies to your setup.

What to ask before hiring security assessment services

Whether you hire a penetration tester or a broader assessment, get written answers:

Scope: will the targets, exclusions, dates and allowed techniques be in a signed document before work starts?
Method: which methodology do they follow, and how much of the work is manual rather than a relabeled scanner report?
People: who does the testing, with what experience, and is any part subcontracted?
Safety: how do they avoid disrupting production, and who can stop the test?
Data: what do they collect, where is it kept and when is it deleted?
Report: will each finding include evidence, steps to reproduce, the reasoning behind its severity and a concrete fix?
Retest and price: is a retest of fixed items included, and what would change the quote?

Be cautious of anyone who guarantees a site cannot be breached.

Where ASL Scan fits

ASL Scan, listed as Live, is not a self-serve scanner you point at a URL. ASL delivers it as an authorized engagement for managed service providers, security consultants and IT leads, and an analyst reviews every report before it reaches a client. A signed authorization names the exact hosts, platforms, approver and expiry, and the check refuses anything outside it.

Its read-only check runs on Windows and Linux machines, measures 35 hardening controls such as firewall, disk encryption and remote-login settings, and flags 16 sensitive service ports. Each control returns pass, fail, unknown or not applicable, and an unknown never counts as a pass. Results are sealed with a tamper-evident fingerprint. The product page also lists a deep authorized web-assessment pack of 150 controls.

Limits: it is not a compliance certification, and a passing check does not prove a system is free of flaws. There is no customer portal; you receive the reviewed report and the sealed evidence bundle. Its heavier active-attack tier is only for owner-approved disposable systems. Pricing is quoted per engagement. See how ASL Scan works.

Frequently asked questions

Is it legal to scan a website for vulnerabilities?

Scanning your own site, or one you have written permission to test, is normal practice. Scanning someone else's site without permission can expose you to criminal or civil liability under federal and state computer crime laws, which vary by state.

What is the difference between a website vulnerability scanner and website penetration testing?

A scanner checks automatically for known weaknesses, and a person must confirm the results. A penetration test is led by a human who mimics an attacker, combines weaknesses and shows the real impact within an agreed scope.

Are free website vulnerability scanners good enough?

For known issues on your own site they can be, if someone configures them well and reads the results critically. They do not replace a human test of logins, permissions and business logic.

How often should I run a website security scan?

After every significant change and on a regular schedule, such as monthly. Sites that take card payments may also have PCI DSS requirements, including passing scans by an Approved Scanning Vendor at least every three months.

Can a vulnerability scan take my website down?

An active scan can; NIST notes that scanning traffic can affect the systems being scanned. Start with a passive scan, test a staging copy when possible and turn off denial-of-service checks.

Related guides

Explore the complete product

Read features, current access and limitations

Website Vulnerability Scanner Guide: What It Finds, What It Misses and When to Test