Safeguard
AppSec

How to Scan a Website for Vulnerabilities Free: Tools and Method

You can scan a website for vulnerabilities free with ZAP, Nuclei, testssl.sh, and a few hosted checkers — if you follow a method instead of pushing buttons. Here is the workflow.

Marcus Chen
DevSecOps Engineer
6 min read

To scan a website for vulnerabilities free, combine one active scanner (ZAP or Nuclei), one TLS checker (testssl.sh or SSL Labs), and one HTTP-header analyzer (Mozilla Observatory), run against a site you are authorized to test — the tools are genuinely free; the discipline is supplying the method. Point-and-click "free website scanner" pages mostly check headers and TLS. Real coverage takes about an hour of setup, and this post walks through it end to end.

One rule before anything else: only scan systems you own or have written permission to test. Active scanning sends attack-shaped traffic. Against someone else's site it is potentially a crime in most jurisdictions, and against your own production it can fill databases with junk or trip rate limits, which is why staging is the better default target.

What "free" actually gets you

A useful mental model splits website scanning into four layers, each with a solid free option:

LayerWhat it findsFree tool
TransportWeak TLS versions, bad ciphers, cert issuestestssl.sh, SSL Labs
ConfigurationMissing security headers, cookie flagsMozilla Observatory, ZAP passive scan
ApplicationXSS, SQL injection, open redirects, auth issuesZAP, Nuclei, Wapiti
Known-vulnerable stackOutdated CMS/plugins, exposed panels, known CVE patternsNuclei templates, Nikto

No single free tool covers all four well, which is why the method below chains them.

Step 1: passive reconnaissance first

Start with checks that send only normal traffic, so you can run them against production safely.

TLS: clone and run testssl.sh — it needs nothing but bash and openssl:

git clone --depth 1 https://github.com/testssl/testssl.sh.git
cd testssl.sh && ./testssl.sh https://staging.example.com

It flags deprecated protocol versions, weak cipher suites, and certificate chain problems in a few minutes.

Headers and cookies: Mozilla's HTTP Observatory (developer.mozilla.org hosts it under HTTP Observatory) grades your Content-Security-Policy, HSTS, frame protections, and cookie attributes. A hosted check by securityheaders.com gives a similar quick read. These catch the misconfigurations that make every other bug worse.

Step 2: a baseline active scan with ZAP

ZAP (now ZAP by Checkmarx, formerly OWASP ZAP) remains the workhorse free web application scanner. Its baseline mode spiders the site and runs passive checks only, so it is safe enough for most environments:

docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t https://staging.example.com -r baseline-report.html

For a genuine attack-surface test, the full scan adds active payloads — XSS probes, SQL injection tests, path traversal attempts:

docker run -t ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py \
  -t https://staging.example.com -r full-report.html

Expect a full scan to take from twenty minutes to several hours depending on how many URLs the spider finds. If your app is mostly behind a login, an unauthenticated scan tests almost nothing; ZAP supports scripted authentication, and configuring it is the single biggest coverage upgrade most teams skip. We cover that setup in detail in ZAP security testing.

Step 3: known-vulnerability templates with Nuclei

Where ZAP probes generic bug classes, Nuclei checks your site against thousands of community-maintained templates for specific known issues: exposed admin panels, default credentials pages, misconfigured cloud metadata endpoints, and fingerprinted CVEs in common software.

nuclei -u https://staging.example.com -severity medium,high,critical

Nuclei is fast and its findings are unusually actionable, because a template match usually means a specific named issue rather than "possible anomaly." Keep the templates updated (nuclei -update-templates); the value is in the freshness.

Nikto still earns a place for old-school server misconfiguration checks (dangerous files left in webroots, outdated server banners), though its findings need more manual triage.

Step 4: check vulnerability of a website's dependencies

A website scanner vulnerability report only sees what is exposed over HTTP. Much of your real risk sits in the stack behind it: the framework, libraries, and container images. If you have repo access, free scanners close that gap — npm audit, pip-audit, OSV-Scanner, and Trivy for images all cost nothing:

osv-scanner --lockfile package-lock.json
trivy image yourregistry/yourapp:latest

Dynamic scanning and dependency scanning find almost entirely disjoint bug sets, so treat them as two halves of one job.

Step 5: triage like you mean it

Raw scanner output is where most free scanning efforts die. A workable triage pass:

  1. Deduplicate: scanners repeat one root cause (a missing header, a template echoing input) across hundreds of URLs. Group by root cause, not URL.
  2. Verify the top items manually: replay the request the scanner made and confirm the behavior. DAST false positives concentrate in reflected-XSS and blind-injection heuristics.
  3. Rank by exploitability, not scanner severity: an unauthenticated SQL injection outranks fifty missing headers.
  4. Fix classes, not instances: one output-encoding fix or one redirect allowlist typically clears dozens of findings.

When to move beyond free ad-hoc scans

The free stack above is excellent for a point-in-time answer to "how exposed are we right now." Where it strains is repetition: scheduling scans on every release, tracking findings across runs, scanning authenticated flows reliably, and reporting trends. If you find yourself scripting scan orchestration and building a findings database in spreadsheets, that is the point where a managed DAST platform earns its keep — and entry pricing for hosted scanning is generally cheaper than the engineering time spent maintaining glue scripts.

To scan vulnerability online without installing anything, the hosted options are a reasonable start (SSL Labs, Observatory, securityheaders.com), but understand their limit: they assess your perimeter configuration, not your application logic.

FAQ

Can I really scan a website for vulnerabilities free, or is it all upsell?

The core tools — ZAP, Nuclei, Nikto, testssl.sh, OSV-Scanner, Trivy — are fully free and open source, with no capability paywall. What paid products add is orchestration, authenticated-scan reliability, triage workflow, and support, not fundamentally different detection.

Is it legal to scan any website?

No. Active scanning without authorization is unlawful almost everywhere. Scan your own systems, or get written permission. Hosted passive checks of public headers and TLS are generally fine because they send ordinary requests.

How often should I scan?

Passive checks: continuously or weekly, they are free to run. Active scans: on every significant release, or weekly on staging. New template releases for Nuclei are worth re-running promptly, since they track newly published vulnerabilities.

Why did my scan find nothing — is my site secure?

Probably not; it usually means the scanner never got past your login page or a WAF filtered its probes. Check crawl coverage (how many URLs were actually tested) before celebrating an empty report.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.