What a Free Website Security Scan Actually Checks

Search for a website security scan free tool and you'll find dozens of options promising to grade your site in seconds. But the difference between a useful scan and a vanity report comes down to what's actually being checked — and whether the output is something you can act on Monday morning.

This post breaks down what a meaningful free scan should cover, what each check is looking for, and how to interpret common failures. If you build or maintain sites for a living, this is the baseline you should be running on every project before launch.

What gets tested in a proper external scan

A non-invasive scan inspects what your server tells the public internet — TLS handshakes, response headers, cookie flags, DNS records, and CORS behaviour. It doesn't touch your database or application logic, but it surfaces a surprising number of real issues.

1. SSL/TLS configuration

Having a green padlock isn't the same as having a well-configured certificate. A good scan checks:

• Protocol versions — TLS 1.2 and 1.3 should be enabled; TLS 1.0 and 1.1 must be disabled
• Cipher suites — weak ciphers like RC4, 3DES, or anything with CBC in TLS 1.2 should be gone
• Certificate chain — intermediates must be served correctly (a common Nginx misconfiguration)
• Expiry window — anything under 30 days needs renewal automation
• HSTS — is Strict-Transport-Security set, and is the max-age at least 31536000?

Real example: a site we recently audited had a valid Let's Encrypt cert but was missing the intermediate. Browsers worked fine; Java HTTP clients and older Android devices failed silently. The scan caught it in seconds.

2. Security headers

This is where most sites lose marks. The headers that actually matter:

• Content-Security-Policy — the single most impactful header you can set
• Strict-Transport-Security — forces HTTPS for future visits
• X-Content-Type-Options: nosniff — stops MIME sniffing attacks
• X-Frame-Options or CSP frame-ancestors — clickjacking protection
• Referrer-Policy — controls what's leaked in the Referer header
• Permissions-Policy — locks down browser features like geolocation, camera, mic

3. Content Security Policy quality

Having a CSP isn't enough — a bad one is almost worse than none. A serious scanner checks for:

• unsafe-inline in script-src (defeats the purpose of CSP)
• unsafe-eval usage
• Wildcard sources like * or https:
• Missing object-src 'none' and base-uri 'self'
• Whether frame-ancestors is defined

4. Cookie flags

Every cookie set by the response is inspected for:

• Secure — only sent over HTTPS
• HttpOnly — not accessible from JavaScript
• SameSite — set to Lax or Strict unless you need cross-site behaviour

Session cookies missing HttpOnly are the #1 finding on most WordPress and custom PHP sites.

5. DNS hygiene

DNS issues that affect email deliverability and brand trust:

• SPF — exactly one record, with the right includes
• DMARC — published with at least p=quarantine
• DKIM — selector records for your sending services
• CAA — restricts which CAs can issue certs for your domain

6. CORS policy

Overly permissive CORS is a quiet killer. Watch for:

• Access-Control-Allow-Origin: * combined with Allow-Credentials: true (browsers reject this, but the intent is alarming)
• Reflected origins without an allowlist
• Wildcards on authenticated endpoints

How to choose a free scanner

Not all free tools are equivalent. Use this checklist when picking one:

1. Does it explain failures? A grade of D is useless without "here's the exact header you're missing."
2. Does it test multiple categories in one pass? Running five different scanners and stitching results together wastes hours.
3. Can you re-scan quickly? Fix, re-test, fix again — the loop needs to be fast.
4. Are results shareable? Useful when handing off findings to clients or devs.
5. Is there a clear grade? A single A–F score helps prioritise across a portfolio of sites.

WebSentry was built around this workflow — one scan returns an A–F grade across SSL, headers, CSP, cookies, DNS, and CORS, with the specific fix for each finding rather than a generic link to MDN.

A realistic scan-and-fix workflow

Here's the workflow we recommend for agencies handling multiple client sites:

1. Baseline scan — run the site before any work, save the report
2. Prioritise by impact — fix missing HSTS, CSP, and cookie flags first; these are quick wins worth several letter grades
3. Tackle CSP iteratively — start with Content-Security-Policy-Report-Only, collect violations for a week, then enforce
4. Fix DNS records during low-traffic windows — SPF and DMARC changes can affect email delivery
5. Re-scan — confirm the grade jump and archive the report as proof of work

Common quick wins

Three changes that typically move a site from F to B in under an hour:

• Add Strict-Transport-Security: max-age=31536000; includeSubDomains
• Add X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and X-Frame-Options: DENY
• Set Secure, HttpOnly, and SameSite=Lax on every cookie your app issues

None of these require code changes beyond your web server config or framework middleware. In Nginx it's six lines in your server block; in Express it's the helmet middleware with two options changed.

What free scans won't catch

Be honest about the limits. An external scan can't see:

• SQL injection or XSS in your application logic
• Authentication or authorisation flaws
• Vulnerable dependencies in your build
• Server-side misconfigurations behind a CDN
• Anything requiring login

For those you need DAST tools, SAST in CI, and dependency scanning (Snyk, Dependabot, Trivy). The external scan is your first line — it catches the issues that an attacker sees from outside without authenticating, and those are the ones that get exploited automatically by bots.

If you haven't checked a site recently, run a free scan at websentry.dev and see where you stand. Most sites have at least three of the quick wins above sitting unfixed — and an A grade is usually one afternoon of work away.