What a security scan checks, and what a clean report actually means
A scan tests your site from the outside for known weaknesses. What it checks, what it cannot see, and how to read a report without panic or false comfort.
The short answer
A security scan is an automated examination of your website from the outside. It does what an attacker’s first tools do: check the certificate and headers, look for exposed files and admin pages, identify the software and versions in use, compare them with databases of known vulnerabilities, and probe forms and parameters for the classic injection patterns.
It is fast, repeatable and inexpensive, which makes it the right routine check. It is also limited in ways that matter, which is why a clean report should be read carefully.
What a scan typically checks
| Area | Examples of what is tested |
|---|---|
| Transport | Certificate validity and expiry, protocol versions, HSTS, redirect from HTTP |
| Headers | Content Security Policy, frame protection, content type options, referrer and permissions policies |
| Exposure | Admin pages, backup files, configuration files, directory listings, version information |
| Software | Content system, plugins, libraries, server software, and known vulnerabilities for those versions |
| Input handling | Forms and parameters tested for injection patterns, reflected input, error messages that leak details |
| Cookies and sessions | Security flags on cookies, session handling basics |
| SPF, DKIM and DMARC records on the domain | |
| Information leaks | Comments, source maps, error pages, metadata that reveals structure |
What a scan cannot see
- Logic. Whether a customer can see another customer’s order by changing a number in the address. Whether a discount can be applied twice. Whether a form can be used to send email to strangers. These need a person who understands what the application is supposed to do.
- Access and accounts. Who has admin rights, whether two-factor is on, whether a former employee still has a login. A scan tests the site, not your organisation.
- The next disclosure. A clean scan today says nothing about the vulnerability published tomorrow in a library you use.
- Anything behind a login unless the scan is configured with credentials, which most routine scans are not.
How to read the report
- Group by root cause. Forty findings are often five problems: one missing header appears on every page and counts forty times.
- Sort by severity, then by reach. A critical finding on a page nobody can access without a login is less urgent than a medium one on your public contact form.
- Fix the reachable highs first. Then mediums on anything that accepts input or handles logins. Informational findings last, or never.
- Re-scan after fixing. Both to confirm the fix and to make sure it did not open something else.
- Schedule the next one. Monthly for sites with forms, logins or payments; after every significant change for everyone.
Where a scan fits
A scan is the routine. It catches the missing header, the expired certificate, the plugin that needs updating, the exposed backup file. Those are the majority of real-world incidents at small businesses, which is why the routine matters so much. For the problems a scan cannot see, logic, combinations, business rules, a penetration test with a person behind it is the next level, and we wrote up when you need which.
What this means for you
Run a scan now if you have not in the last quarter. Read it by root cause and reach, fix the reachable highs, and put the next scan in the calendar. Then, if your site handles logins, payments or personal data, ask whether it is time for a person to look as well.
Frequently asked questions
Is a security scan the same as a penetration test?
No. A scan is automated and finds known patterns quickly and cheaply. A penetration test has a person trying to break in, including through logic and combinations a scanner cannot see. A scan is the routine check; a test is the deeper examination. A business website needs regular scans and an occasional test.
Our scan came back clean. Are we secure?
You have no known, automatically detectable problems today. That is good and worth maintaining. It says nothing about weaknesses in how your application behaves, about who has access to your accounts, or about what will be disclosed next month. Clean is a baseline, not a certificate.
The report has forty findings. Where do I start?
Sort by severity, then ask for each high or critical finding whether it is reachable and exploitable in your situation. Fix the reachable highs first, then the mediums on pages that handle input or logins. Many of the forty will be informational or duplicates of one root cause, such as a missing header that appears on every page.
How often should we scan?
After every significant change and at least monthly for a site that handles forms, logins or payments. New vulnerabilities are disclosed continuously, so a scan is a snapshot. Regular scans turn snapshots into a trend you can act on.
Sources
- OWASP Top Ten (accessed 2026-09-11)
- OWASP Web Security Testing Guide (accessed 2026-09-11)