Website Vulnerability Scanning: From Raw Output to the Right Decision

You've opened the scanner output and there are 47 red items staring back at you. One of them is "Critical" and it's 11 PM. The real question isn't what the scanner said; the question is which of these 47 items is actually exploitable on your server. If you start closing all of them right now in alphabetical order, you'll spend two days and the main hole might remain untouched.

A vulnerability scan is a snapshot, not a diagnosis. The tool only says "the version I saw matches the pattern of a known CVE." That's a long way from "this server is exploitable." Your entire job on day one is turning that claim into a defensible yes or no.

Before scanning, put the scope on paper

A scanner without scope just produces noise. Determine three things before the first run: the domains and subdomains you own, the ports that actually serve something, and the services you're allowed to test. If you're working on rented infrastructure, a heavy scan without coordination can look like an attack from the provider's perspective and lead to your IP being blocked.

A practical note: forgotten subdomains have more holes than the main domain. A staging.example.com that was set up six months ago and still runs an old version of WordPress is usually the easiest way in. Build your subdomain list from SSL certificates and DNS records; DNS and network lookup tools are for exactly this stage.

How to run free tools and with which flags

For the web layer, Nmap and Nuclei are a good working combination. Nmap for seeing the attack surface, Nuclei for matching known patterns.

nmap -sV -Pn -T3 --top-ports 1000 -oA scan-web example.com

The -sV flag reads service versions, -Pn skips the initial ping (many firewalls block ICMP and without this flag the scan comes back empty), and -T3 keeps the speed in conservative mode. With -T4 it's faster, but on shared links you'll drop packets and get incomplete results.

For Nuclei, first update the templates and then run with a specific severity:

nuclei -update-templates
nuclei -u https://example.com -severity critical,high -rl 30 -o nuclei-out.txt

The -rl 30 flag caps the request rate at 30 per second. Without it, Nuclei can send as many requests to a small site as a small attack would, and cause a 503 error itself. If the site is behind DDoS protection, lower this rate so you don't get yourself blocked.

Scan from inside the server, not just from outside

An external scan only sees open ports. To see old packages, services listening on localhost, and file permissions, you need to look from the inside too:

ss -tulpn
apt list --upgradable 2>/dev/null | grep -i security

The output of ss often reveals things no external scanner can see: a MySQL listening on 0.0.0.0:3306 when it should only be on 127.0.0.1. This is a real finding and closing it takes five minutes.

Why not every finding is a real vulnerability

You have three categories of findings and you need to handle them separately.

Don't underestimate false positives, and don't overstate them either. A scanner that reads the WordPress version from a meta tag will raise a false alarm when you've removed the version in functions.php but the cache is still serving the old version. The way to verify is a manual request:

curl -sI https://example.com/wp-content/plugins/foo/readme.txt | head -5

If you get 404, the finding is closed. If you get 200 with a version number, the finding is real and should go to the top of the list.

This is where they get it wrong

The most common mistake I've seen is this: the team closes all "High" findings and forgets that the scanner never sees business logic. The result is that three weeks later, an admin with a weak password on a panel with no login attempt limit gives away the whole site. The scanner had marked that path as "healthy" because it had no known CVE.

The sign is obvious too: the security dashboard is green, but in the login log you see hundreds of failed attempts from a single IP. If you don't keep audit logs intact, you won't even see that; retaining audit logs is a prerequisite for any periodic scan, not a side task.

The right order of remediation when time is short

1. Anything reachable from the internet without authentication: open admin panels, public phpMyAdmin, backup files with guessable names.
2. Vulnerable versions with publicly released exploits. Attackers run these without any special knowledge.
3. Misconfigurations: file permissions, security headers, REST API access.
4. Minor information disclosure: service versions, full error messages, directory listings.

Don't change this order. Closing item four before item one feels like progress but doesn't reduce real risk.

A note on cost: automated periodic scanning has a lot of noise and low maintenance; manual scanning with human interpretation is more precise but takes several hours each time. If your site has fewer than ten services, I'd choose a monthly manual scan. If you have more than fifty services, automation is mandatory, but someone needs to review the output weekly, otherwise the reports pile up unread.

After remediation, scan again and record the difference

Every remediation without a confirmation scan is an assumption. After closing a finding, run the same command again and keep the before and after output side by side. This has two benefits: it confirms the fix actually worked, and it shows you which findings come back every time. A finding that returns three scans in a row means you haven't closed its root cause; you've only erased its symptom.

If you work with WordPress, a large portion of these findings come from two places: abandoned plugins and an open REST API. Do securing the WordPress REST API and WordPress hardening before the next scan so the list starts shorter.

And one point that's often overlooked: if your server isn't behind a network protection layer, scanning is only part of the picture. Some of the attacks you don't see in the report are exactly the ones that should be filtered before reaching the application. DDoS protection covers this layer and complements scanning, it doesn't replace it.

If you want to turn this cycle into a routine, start with a small, scoped scan, interpret the output manually, and only move to automation after you understand which findings matter for your infrastructure. For the services you'll need along the way, ServerNet's server security services are a good starting point.

Frequently asked questions

Does a website vulnerability scan slow the site down?

Yes, if you don't limit the request rate. Scanners like Nuclei without the -rl flag can send hundreds of requests per second and on small servers cause increased response times or 503 errors. With a rate of 20 to 30 requests per second and running the scan during low-traffic hours, you won't see a noticeable effect on real users.

Why does the scanner find nothing but the site has been hacked?

Because the scanner only sees known patterns. If the breach happened through a weak password, token disclosure, or a logic vulnerability in your custom code, there's no CVE to match against. In this case you need to go through access logs, modified files, and suspicious user accounts, not the scanner.

How often should I scan?

For dynamic sites with multiple plugins, at least once a month. After every major update or new plugin installation, a targeted scan is also needed. Daily scanning on static infrastructure usually produces noise and no one reads the output.

Is scanning from outside enough or should I also run it from inside the server?

Both are needed. An external scan shows the real attack surface, but it doesn't see services listening only on localhost or incorrect file permissions. The ss -tulpn command on the server itself reveals in seconds things no external scanner has access to.