Step-by-step guide
How to scan a website for vulnerabilities
You can learn a lot about your own site for free in an afternoon. Here is the order to do it in, which tools to use, and the things no scan will ever tell you.
By the Bug Circuit security team · Last updated
Step 1: Only scan what you own
Scanning a website without the owner’s permission is a crime in most countries, for example under the US Computer Fraud and Abuse Act, the UK Computer Misuse Act and Sri Lanka’s Computer Crimes Act No. 24 of 2007. Scan your own site, or one where you hold written permission. Passive tools that only read public information are safe on any site you own. Active scanners send attack-style traffic, so use a staging copy where you can, and warn your host if the site is on shared hosting.
Step 2: Run a passive check
A passive check never sends attack traffic. It maps what an attacker can see: subdomains you forgot, the technology and versions in use, DNS records and email security. Forgotten subdomains and old test sites are among the most common real findings.
- Free website security check: subdomains, technology, SSL, DNS and email in one pass.
- Subdomain finder and website technology checker.
Step 3: Check headers, TLS and email authentication
These are quick wins that scanners and attackers both look at first.
- Security headers checker: HSTS, Content-Security-Policy, X-Frame-Options and more.
- SSL certificate checker: expiry, chain and protocol problems.
- Email spoofing checker: SPF, DKIM and DMARC, so nobody can send mail as your domain.
- DNS record lookup: check for dangling records that point at services you no longer use.
Step 4: Run an active scanner on a copy
An active scanner crawls your site and tries common attacks. A few well-known free options:
| Tool | What it does | Good to know |
|---|---|---|
| ZAP | Crawls the site, finds common web flaws such as XSS and injection, and has a passive baseline mode. | The baseline mode is safe on production. A full active scan belongs on staging. |
| Nikto | Checks the web server for dangerous files, old versions and misconfigurations. | Noisy. Expect a lot of low-value results. |
| Nuclei | Runs community templates that look for known vulnerabilities and exposed panels. | Only as good as the templates. Great for known CVEs. |
| WPScan | Checks WordPress core, plugins and themes against known vulnerabilities. | WordPress only. Needs an API token for full data. |
Run scans outside busy hours, rate-limit them, and expect them to submit forms and create test data. Never point an active scanner at someone else’s site.
Step 5: Check your dependencies
Many real compromises come from a known flaw in a plugin, theme or library that was never updated. List what you run and check each against its vulnerability database: your CMS’s plugin directory notes, GitHub security advisories, and package tools such as npm audit for JavaScript projects. Update, or remove what is abandoned.
Step 6: Sort the results
A scan can return hundreds of lines. Fix in this order: anything critical or high that is reachable without logging in, then anything that exposes data, then the rest. Many findings are informational and do not apply to your setup, so do not chase every line. If you want a person to sort them for you, a manual audit does exactly that.
What a scan finds, and what it cannot
| A scan usually finds | A scan usually misses |
|---|---|
| Missing or weak security headers | Broken access control: one customer reading another customer’s data |
| Outdated software with known vulnerabilities | Business-logic flaws, such as skipping a payment step |
| Exposed files, backups and admin panels | Chained issues that are harmless alone and serious together |
| Common injection and XSS patterns in forms | Flaws that need a login, several steps or knowledge of your app |
| Expired or misconfigured certificates | Weak password-reset and session handling that looks normal to a tool |
The classic example: change /orders/1042 in a link to /orders/1041 and see someone else’s order. A scanner sees a normal page. A person sees the problem. That gap is why manual and automated testing are not the same thing.
Step 7: Test the logic by hand
When the scan is clean and the dependencies are current, the remaining risk is in how your app behaves. This is where a manual security audit pays for itself: a person logs in as each role, tries the actions they should not be able to do, and writes up every issue with the evidence and the fix.
- Free check: start with the passive scan. Nothing touches your site.
- Circuit, $49 one-time: a person tests your site by hand and sends a full written report. See a sample report.
- Signal, $147 every 3 months: adds fixes for the high and critical issues, re-tests every 6 months and weekly checks.
Details and the 14-day money-back guarantee are on the pricing page.
Frequently asked questions
How do I scan my website for vulnerabilities?
Is it legal to scan a website for vulnerabilities?
What is the best free website vulnerability scanner?
Does a clean scan mean my website is secure?
What is the difference between a vulnerability scan and a penetration test?
How often should I scan my website?
Can a scanner find SQL injection and XSS?
Keep reading
Start with the free passive check
See what attackers can see about your website in seconds. No login, no card, nothing touches your site.
Ready for the full manual audit? See pricing