Website Security: How to Check and Improve Your Score

A “website security score” is a single, comparable measure of how exposed your site looks from the outside — before anyone logs in, and before any attacker has done anything intrusive. SecScan’s checker turns that exposure into an A–F grade so you can see, in one glance, whether your public-facing configuration is reassuring or alarming. This guide explains exactly what the grade measures, how it is calculated (including the penalties and hard caps that prevent a single bad leak from being averaged away), why we deliberately do not show version-guessed CVEs on the open score, and the fastest order in which to fix things and re-scan.

If you want to jump straight to a specific task, these companion guides go deeper on the practical steps:

What does a “website security score” actually mean?

Your external security posture is the sum of everything a stranger can observe about your site without authenticating and without attacking it. When a browser or curl connects to your domain, it negotiates a TLS handshake, receives response headers, and can request whatever paths happen to be reachable. All of that is public by definition. A website security score reads those same signals and grades how well your configuration protects visitors and how much it accidentally reveals.

It is important to be precise about what this is not. A passive score is not a penetration test — it does not try to log in, submit forms, fuzz parameters, exploit a vulnerability, or pivot through your infrastructure. It does not see your application logic, your database, your internal network, or anything behind authentication.

Instead, it measures the shape of your front door: is the lock modern, is the door labelled with your exact tech stack, and did someone leave a box of keys on the doorstep? That is genuinely useful — most opportunistic compromises and embarrassing data leaks start with exactly these externally visible mistakes. But it is a starting point, not a clean bill of health.

Which signals go into the grade?

SecScan builds the score from external, passive signal groups, each weighted by how much it actually affects real-world risk. There are three signals that change your grade and one that is purely informational.

HTTP security headers (~30%)

Response headers tell the browser how to behave defensively. The check looks for the presence and sanity of headers such as Strict-Transport-Security (HSTS), Content-Security-Policy, X-Content-Type-Options, X-Frame-Options (or a CSP frame-ancestors directive), and Referrer-Policy. Missing or weak headers leave visitors more exposed to downgrade attacks, clickjacking, MIME sniffing, and cross-site scripting. Headers are cheap to fix and high-leverage, which is why they carry roughly a third of the weight. For a header-by-header walkthrough, see the security headers checker.

TLS / SSL configuration (~30%)

This group inspects the certificate and the transport itself: is the certificate valid, trusted by public roots, and not expired (or expiring imminently)? Does the hostname match? And critically, which protocol versions does the server accept? SecScan expects TLS 1.2 or higher and penalizes servers that still offer the deprecated, broken TLS 1.0 and 1.1. A site can serve a perfect certificate and still score badly here if it negotiates obsolete protocols. Because broken transport undermines everything else, TLS also carries roughly a third of the weight.

Exposed files & endpoints (~25%)

This is the check that most often produces a genuinely serious finding. SecScan requests a curated list of paths that should never be publicly reachable — a live .git/ directory, a .env file, database dumps, .bak backups, exposed admin panels, and similar. An accessible source repository or environment file can leak credentials, API keys, and your entire codebase, so a confirmed hit here is treated as critical.

Fingerprint / technology detection (~15%, INFO only)

Finally, SecScan fingerprints the technology stack — server software, frameworks, CMS, and visible version banners. This signal is informational only. It is reported so you understand what you are exposing and can decide whether to suppress version banners, but it does not by itself push your letter grade down. Knowing you advertise an exact framework version is useful context; it is not, on its own, proof of a vulnerability.

How is the A–F grade calculated?

Each category starts at 100 points. Individual findings subtract points according to severity — a critical issue removes far more than a low one. The per-category scores are then combined using the weights above (headers ~30%, TLS ~30%, exposed files ~25%, fingerprint ~15% as INFO) to produce a single 0–100 number, which maps to an A–F letter.

But a pure weighted average has a dangerous flaw: it lets a strong performance in two categories quietly absorb one catastrophic finding in a third. A site with flawless headers and TLS but a publicly cloneable .git directory is not a B-grade site — its source code is on the internet. To prevent that kind of misleading averaging, SecScan applies hard caps on top of the weighted score:

• Any critical issue caps the overall grade at F, regardless of how clean the rest of the scan is. An exposed source repo or environment file is, by itself, a failing condition.
• Any high-severity issue caps the grade at C. You cannot earn an A or B while a high finding is outstanding, even if the numeric average would suggest otherwise.

In other words, the weighted average sets your ceiling when everything is healthy, and the caps pull you down hard the moment something genuinely serious is visible. A high average can never hide a single critical leak. This is intentional: the grade is meant to reflect the worst thing an attacker can see, not the comfortable middle of your configuration.

Why are version-based CVEs excluded from the open score?

It is tempting to read a version banner — say, a server header advertising a specific release — look it up in a vulnerability database, and report every matching CVE as a finding. Many scanners do exactly this. SecScan deliberately does not, and on a YMYL (your-money-or-your-life) topic like security it is worth explaining why honestly.

Inferring a CVE purely from a version string is unreliable. Vendors backport security patches without changing the advertised version, distributions ship their own patched builds, banners are frequently spoofed or stripped by proxies and CDNs, and a given CVE may only apply under a configuration you do not run.

The result is a flood of false CRITICALs — alarming red findings that often turn out to be wrong. False criticals are not a harmless inconvenience: they erode trust in the whole report, push owners to waste time chasing phantom problems, and ultimately train people to ignore the scanner. A score you cannot trust is worse than no score.

So the open A–F score sticks to signals it can directly observe and confirm: the actual headers returned, the actual TLS the server negotiates, and files that actually respond. The fingerprint stays INFO-only for the same reason. Checks for known-exploited vulnerabilities — cross-referenced against the CISA Known Exploited Vulnerabilities (KEV) catalog — are reserved for the authenticated full external scan, where there is enough verified context to report them responsibly rather than guess.

How do you raise your grade fastest?

Because of the hard caps, the order of operations matters enormously. Work top-down by severity, not by category. Here is the sequence that moves your grade fastest:

1. Close exposed files and endpoints

These cause critical findings, and a single critical caps you at F. This is always step one. Make sure no .git/, .env, backup archive, or database dump is reachable over the web. A quick way to confirm a fix from your own machine:

# Should return 404 — not 200 with a real config block
curl -sI https://example.com/.env | head -n 1
curl -sI https://example.com/.git/config | head -n 1

If either returns 200 OK with real content, that is your top priority — rotate any leaked secrets immediately, then block the path at the web server or move the artifact out of the document root.

2. Fix your TLS configuration

Next, clear any high-severity transport findings. Renew or replace a certificate that is expired, untrusted, or mismatched, and disable TLS 1.0 and 1.1 so the server only negotiates TLS 1.2 or higher. These changes remove the C cap that a high TLS finding can impose.

3. Add and tighten security headers

With the caps cleared, headers are where you climb from a passing grade toward an A. Add HSTS, a sensible Content-Security-Policy, X-Content-Type-Options: nosniff, frame protection, and a Referrer-Policy. The security headers checker and our headers guide walk through safe values for each. While you are reviewing what your domain exposes, it is worth confirming your email authentication too — SPF, DKIM, and DMARC sit just outside the website score but are part of the same external posture; check them with the email DMARC checker.

4. Re-scan and confirm

Re-run the scan after each change. The score updates against what you have actually deployed, so you get immediate confirmation that a critical is gone or a header is now in place. Re-scanning also catches regressions — a config rollback or a new subsystem that quietly re-exposes a path.

How do you check your site?

You can run the passive scan now — it only needs your domain, and it sees exactly what any visitor’s browser sees. You will get an A–F grade, the per-category breakdown across headers, TLS, and exposed files, and a prioritized list of findings ordered so you know which cap to clear first.

Prefer to go straight to the tool? Open the website security score checker and enter your domain.