What an automated security scan can and cannot tell you

Automated security scans are quick, cheap or free, and genuinely useful. They are also easy to misread. A good score does not mean a site is secure, and a long list of findings does not always mean it is in trouble. Here is what a scan can and cannot tell you, and how to get the most from one.

What a scan is good at

A scanner checks things it can observe and compare against known rules:

• Configuration you can see from outside: HTTPS, certificates, redirects, security headers and cookie settings.
• Exposed files: .env files, .git folders, backups and public API descriptions.
• Mixed content: pages served over HTTPS that load scripts or images over plain HTTP.
• Known-vulnerable dependencies: package versions that match published security advisories.
• Recognisable code patterns: hard-coded secrets, database queries built from strings and dangerous functions.

Scanners are fast and consistent, which makes them good at catching the common, boring mistakes that cause real breaches. They are also ideal for re-checking after every change.

What a scan cannot tell you

• Whether your business logic is safe. A scanner does not know that a customer should not be able to change the price in a checkout request, or apply the same discount code twice.
• Whether users can see each other's data. Checking that customer A cannot open customer B's invoice needs an understanding of who owns what.
• Anything behind a login, unless the scan is set up with access.
• Whether a finding really matters in your context. A missing header on a static brochure site and the same header missing on a banking dashboard are different risks.
• New, unknown attacks. Scanners recognise known patterns.

So a clean report means the scanner did not find the problems it looks for. It is good news, but it is not proof that nothing is wrong.

Scan, review or penetration test?

• Automated scan: fast, broad and repeatable. Best for catching common mistakes, and for regular checks.
• Reviewed assessment: a person checks the scanner's findings against your actual application, removes false alarms and puts the rest in order of real risk. Best when you need to know what to fix first.
• Penetration test: a tester actively tries to break in, within an agreed scope, including logic and access-control flaws. Best for applications that handle money or sensitive data, and often needed for compliance.

They are not competitors. Most teams should start with a scan, fix what it finds, and bring in a person for the parts that matter most.

Getting the most from a scan

1. Fix the easy findings first. Headers, cookie settings and exposed files usually take minutes.
2. Read the evidence, not just the title. Good reports show what was observed, so you can confirm a finding before acting on it.
3. Re-scan after every significant change, or schedule regular scans so you notice when something regresses.
4. Get a person to look at what the scanner cannot, especially payments, sign-in, personal data and admin areas.

Our free scanner checks websites, ZIP files and repositories and shows the evidence for every finding. When you need someone to look at the rest, we review findings in context and fix what matters.