You can check your own website for known vulnerabilities yourself, without waiting for an incident. There are free scanners for this: nuclei works from templates, nikto checks the web server, and wpscan examines WordPress. This article explains how to run them against your own resources, how to read the result, and how scanning differs from a penetration test.
The boundary: your own resources only
Scanners send hundreds of requests to a server, and some of them look like attack attempts. Run them only against sites that you own or that you have written permission to test. Scanning someone else's resource without consent may break the law and the hosting provider's rules. If the site is on a shared server, warn support and choose a time with low load. The best option is to test a staging copy rather than the production site.
What each tool checks
The tools complement each other. None of them replaces the others, and the result of each must be verified manually.
| Tool | What it checks | Output |
|---|---|---|
| nuclei | Known vulnerabilities, misconfigurations and exposed panels via templates | A list of findings with severity levels |
| nikto | The web server: outdated software, dangerous files, insecure headers | A text report with links to descriptions |
| wpscan | WordPress: core version, plugins, themes, users | A list of components and known issues |
nuclei: template-based checks
Nuclei runs sets of YAML templates, each of which describes one check. Update the templates before you start, then limit the severity and the speed so that the server is not overloaded. The -o option saves the result to a file.
nuclei -ut
nuclei -u https://example.com -severity medium,high,critical -o nuclei.txt
nuclei -u https://example.com -rate-limit 10nikto and wpscan
Nikto looks for problems at the web server level: old versions, forgotten files, directories with listing enabled, missing security headers. It is noisy and produces many false positives, but it quickly shows obvious shortcomings.
apt install -y nikto
nikto -h https://example.com -o nikto.txtWpscan is built for WordPress. The --enumerate parameter with the set vp, vt and u lists vulnerable plugins, themes and users. To get vulnerability data you need a free API token from the project: without it the utility shows only component versions.
gem install wpscan
wpscan --url https://example.com --enumerate vp,vt,u
wpscan --url https://example.com --api-token TOKENHow to read the report
A scanner finding is a hypothesis, not a verdict. Verify it manually before changing anything.
- The info level describes the system rather than a vulnerability; start with high and critical.
- False positives are common: check the version and the conditions under which the problem is reproducible.
- An exposed server or plugin version is not a breach by itself, but it makes it easier to pick an attack.
- After fixing, repeat the scan and make sure the finding is gone.
Scan versus penetration test
A scanner automatically matches your site against a database of known problems. A penetration test is the work of a specialist who follows an agreed plan to examine application logic: access rights, payment bypass, chains of several small mistakes. A scanner will not find what is missing from its templates and does not understand business logic. A scan suits regular hygiene, while a penetration test suits important systems.
Work through the findings in order. For application dependencies there is the check described in dependency audit with npm audit and composer audit, for the server there is the Linux server security checklist, and for a WordPress site there is WordPress protection on the server. Web server settings are covered in Hardening Nginx.
Frequently asked questions
Is it legal to run a scanner against my own site?
Testing your own resource is legal, but the rules of the platform still apply. If the site is on a shared server or behind a protection service, warn support: frequent requests may look like an attack. Other people's sites must never be tested without the written permission of the owner, under any circumstances.
Can I scan a production site?
You can, but carefully: limit the speed, choose a low-load time and make a backup first. It is safer to test a staging copy that mirrors production. That way the scanner does not load the site for visitors, and questionable checks cannot touch real data.
What should I do if the scanner finds many problems?
Sort them by severity: critical and high first, then the rest. For each finding check whether it is a false positive, and then find the fix: an update, a setting or the removal of an unneeded component. After the changes repeat the scan and keep the reports so you can see the trend.
Does scanning replace a specialist review?
No. A scanner quickly finds known problems, but it does not understand your application logic and will not discover new vulnerabilities. It is handy for regular checks, while critical systems additionally need a manual audit or an agreed penetration test carried out by an experienced specialist.