Free website vulnerability scanners: what they find and what they miss

Free website checks are everywhere now, and that is a good thing: a basic scan has stopped being something you pay for. The trouble is elsewhere — a report rarely makes clear what was actually checked and what was never touched at all. Let us be honest about where the line runs.

What a free scan really does find

Any external scanner works like a visitor to your site: it opens pages, looks at the server's responses and compares what it sees against a database of known problems. Within those limits it turns up plenty that matters:

• Outdated versions of your CMS and its components. The version of WordPress, 1C-Bitrix, jQuery or nginx is often visible right in the server response — and published vulnerabilities (CVE) are tied to versions.
• Files that should never be reachable from outside: an exposed .git directory, a forgotten .env, a dump.sql backup, configuration files.
• Missing security headers — Content-Security-Policy, Strict-Transport-Security, protection against your site being embedded in someone else's frame.
• Certificate and encryption problems: an expiring certificate, support for obsolete protocols.
• Exposed service pages: admin panels, debug pages, phpinfo, monitoring interfaces.
• Login with a default password. A check for whether the admin panel opens to something like “admin/admin” — a rare find, but the most expensive one of all.

That is enough to catch most of the typical problems a small site has. If you have never checked your site, start with any free scanner — ours included. That is honest advice: the first check almost always finds something.

What no one-off free scan will show you

This is where the line runs — the one reports usually stay quiet about.

1. Everything behind the login form

An anonymous scanner sees your site the way a passer-by does. The customer account, the control panel, checkout, document uploads — the entire private side goes unchecked. And that is exactly where the nastiest problems live: reading someone else's order by changing a number in the address bar, uploading an executable file instead of a picture, a template editor that lets you overwrite a file on the server.

2. Your business logic

A scanner does not know that a discount must never exceed 100%, that someone else's contract must not be downloadable from a direct link, or that a courier has no business seeing every customer's phone number. Vulnerabilities like these are found by hand — that is a pentester's job, and it costs a different kind of money. Any automated tool that promises to “find every vulnerability” is leaving something out here.

3. Your code and whatever was left in it

A payment gateway key that made it into the repository, a database password in the commit history, a dependency with a known vulnerability — none of that is visible from outside at all. It takes an analysis of the repository itself.

4. What shows up tomorrow

This is the big one. A scan is a photograph of a single day. Vulnerabilities in popular plugins are published every week: today your site is clean, and ten days later a CVE lands in the contact form plugin you happen to run. Your site has not changed — what is known about it has. A one-off free check will not tell you, because it is already over.

5. How dangerous a finding is for you specifically

A list of forty items graded “critical / high / medium” does not answer the owner's question: what do I start with on Monday? Three “high” risks can be harmless, while a single “medium” one opens a path to your customer database.

How this differs from the antivirus your host sells for a few dollars a month

A common mix-up. A hosting antivirus and a vulnerability scanner solve different problems, and neither replaces the other.

So the argument “why pay when my host already has a check for a few dollars a month” does not hold: you are comparing cleaning up after a fire with a fire alarm. You need both.

Check it yourself in five minutes — no scanner needed

Four things you can see from a browser, no tools required:

1. Open your-site.com/.git/config. If the browser shows text instead of a 404 error, your site's source code is available to anyone. This is fixed the same day, and it happens more often than you would think.
2. View the source of your home page (Ctrl+U) and search for generator. It often spells out the CMS version in plain text — and with it, the list of vulnerabilities that fit.
3. Check the address. Does the site open over http:// without redirecting to https://? If it does, your customers' passwords travel the network in plain text.
4. Go to /wp-admin or /bitrix/admin. Is the login form open to the whole internet? That is not a vulnerability in itself, but it is a door that automated password guessers knock on around the clock.

If all four are in order, you have the basic hygiene covered, and it makes sense to talk about regular checks from there. If not, start with these — it is cheaper than any subscription.

What to do with the report once you have it

1. Separate what you can fix yourself (update a plugin, close off a file, turn on the redirect to https) from what needs a developer.
2. Start with what is reachable from outside, not with the formal risk score: an exposed configuration file matters more than a theoretical vulnerability in a library you do not even use.
3. Re-check after you fix things. A report without a re-check is a hypothesis that you fixed everything.
4. Keep the list. Six months from now it will show you what came back — and things do come back.