Article

How to Improve Your Website Security Score

Improve your website security score by working top-down by severity: first close any exposed files that cap the grade at F, then fix TLS (valid cert, TLS 1.2+), then add the core security headers, and re-scan after each change to confirm the gain.

By Paul Rudenko, Security ResearcherUpdated Jun 26, 20267 min read

Improving a website security score is rarely about adding more of everything. SecScan grades what an external visitor can observe about your site, and the model is weighted so that a single serious problem outranks a long list of minor ones.

That means the fastest way to a better grade is to work in order of severity: clear anything that caps the grade first, then raise the average. This guide walks through that order step by step, with a re-scan after each change so you can confirm the gain rather than guess at it.

For the site owner (plain English)

If the letter grade looks discouraging, don’t panic — it is a to-do list, not a verdict. The key thing to understand is that one serious problem can hold the whole grade down no matter how good everything else is, so the goal is to fix your single worst issue first, not to do a little of everything. There is no rush, but a low grade usually points at something cheap to fix — a private file left in the open, or an expired certificate. The simplest path: run the free scan, look at the top finding it flags, hand that one item to whoever maintains your site, then re-scan to watch the grade move. Work down from there, one issue at a time.

How does the score work (quick recap)?

SecScan's score is a weighted blend of four observable categories. Headers contribute roughly 30%, TLS configuration roughly 30%, exposed files roughly 25%, and an information-only fingerprint of the server and technology stack the remaining ~15%. Each category starts at 100 points and loses points as issues are found, scaled by how serious each issue is. The weighted result is then mapped to a letter grade from A to F.

Two hard caps sit on top of that average and they are the most important thing to understand. Any single critical finding caps the whole grade at F. Any single high finding caps it at C.

A cap overrides the average entirely: it does not matter how clean the other categories are, the cap holds until the underlying finding is cleared. That is why order matters more than volume. For the full model, see the website security guide.

Step 1 — Which exposed files cause the F cap?

Exposed files are the category most likely to produce a critical finding, and a critical finding caps your grade at F. Before touching anything else, confirm that no sensitive paths are reachable over the public internet. The usual offenders are version-control directories, environment files, and stray backups.

A publicly readable .git directory, which can let anyone reconstruct your source code and its history.
An .env file or similar dotfile exposing database credentials, API keys, or signing secrets.
Backup and archive files such as backup.zip, site.sql, or editor leftovers like config.php.bak.

Remove these from the document root or block them at the web server. With nginx you can deny access to dotfiles and common backup patterns:

location ~ /\.(?!well-known) {
    deny all;
}
location ~* \.(bak|sql|zip|tar|gz|old|swp)$ {
    deny all;
}

Removing the file is necessary but not sufficient. If a secret was ever served publicly, assume it is compromised and rotate it — issue new API keys, change database passwords, and invalidate any leaked tokens.

A deleted .env does not un-leak the values that were inside it. Once no critical exposure remains, the F cap lifts and the rest of your work can actually move the grade.

Step 2 — How do you fix TLS (the C cap)?

With criticals cleared, the next ceiling is the high-severity cap at C, and the most common cause is a TLS problem. Transport security is worth roughly 30% of the score on its own, so it pulls double duty: it can cap the grade and it is heavily weighted in the average.

Use a valid, trusted certificate

The certificate must be issued by a trusted certificate authority, match the hostname, and be within its validity window. Expired, self-signed, or mismatched certificates typically register as high findings. A free automated certificate from Let's Encrypt with auto-renewal removes the most common cause — an expired certificate nobody remembered to renew.

Disable obsolete protocols

Serve TLS 1.2 and TLS 1.3 only. Disable TLS 1.0 and TLS 1.1, which are deprecated and weaken the configuration. On most modern servers this is a one-line change to the enabled protocol list. After updating, confirm the certificate chain and protocol support with the SSL checker before moving on.

Step 3 — Which security headers climb you to A?

With both caps cleared, the grade is now governed by the weighted average, and security headers are the most direct way to climb from C toward A. They are also low risk to add, since most are response headers rather than code changes. The OWASP Secure Headers Project is the reference for recommended values. Focus on the core set first:

Strict-Transport-Security (HSTS) — forces HTTPS for future visits and prevents protocol downgrade.
Content-Security-Policy (CSP) — restricts which sources can load scripts and other resources, mitigating injection.
X-Content-Type-Options: nosniff — stops the browser from second-guessing declared content types.
X-Frame-Options or a CSP frame-ancestors directive — prevents clickjacking by controlling who can frame your pages.

A reasonable starting point for an nginx server:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Content-Security-Policy "default-src 'self'" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;

Roll CSP out carefully — start in report-only mode if your pages load third-party assets, so you do not break legitimate resources while tightening the policy. For directive-by-directive guidance see the security headers guide, and verify what is live with the security headers checker.

Step 4 — Re-scan after each change

Treat the scanner as your feedback loop, not a final exam. Re-run a scan after each change rather than batching everything and hoping.

Because the caps work the way they do, a single re-scan tells you whether a fix actually moved the grade or whether another cap is still holding it down. Re-scanning after the exposed-files step, then again after TLS, then after headers, makes the cause and effect obvious and stops you from optimising a category that a cap is currently overriding.

Made a change? Re-run the scan to confirm the grade moved.

Check your A–F score →

Common gotcha: adding more headers will not lift an F. A single critical finding — for example a publicly exposed .git directory — caps the grade at F no matter how clean everything else is. You could earn a perfect headers score and a flawless TLS configuration and still see an F on the report. Clear the cap first, then optimise the average. Working in any other order wastes effort on gains the cap is hiding.

The pattern holds at every level: identify the highest-severity issue, fix it, re-scan, and repeat. Severity-first beats volume-first every time, because the grade is built to reward closing your worst problem before polishing your best category. For a printable working list, use the website security checklist, and for the underlying model in full, return to the website security guide.

Frequently asked questions

How do I improve my website security score fastest?

Work top-down by severity instead of adding fixes at random. Start by clearing any critical findings, which usually means exposed files such as a public .git or .env directory, because a single critical caps your grade at F. Next, fix high-severity TLS issues — install a valid trusted certificate and disable TLS 1.0 and 1.1 — to clear the C cap. Only then add the core security headers (HSTS, CSP, nosniff, frame protection) to climb toward A. Re-scan after each step so you can see whether the grade actually moved. This order matters because caps override the average: a site with flawless headers and a leaked backup archive still scores F, so optimising headers while a critical is exposed produces no visible improvement. The fastest wins are usually configuration changes you already control — a header block, a redirect rule, a directory permission — rather than anything needing new code.

Why is my grade still F after adding headers?

Because a critical finding is still capping the grade. SecScan applies a hard cap: any single critical finding holds the overall grade at F regardless of how good every other category is. Security headers contribute to the weighted average, but the average never overrides the cap. The most common cause is an exposed file — a publicly readable .git directory, an .env file with secrets, or a backup archive in the document root. Until that file is removed and any leaked secrets are rotated, your perfectly configured headers and TLS cannot show up in the letter grade. Find and clear the critical finding first, re-scan to confirm the F cap has lifted, and your earlier header work will then be reflected in the score.

What caps a security grade at F or C?

Two severity-based caps sit on top of the weighted average. Any single critical finding caps the overall grade at F, and any single high finding caps it at C. A cap overrides the category averages entirely, so the grade cannot rise above the cap until the underlying finding is cleared. Criticals are typically exposed files that leak source code or secrets, such as a public .git or .env. Highs are often TLS problems — an expired, self-signed, or mismatched certificate, or support for obsolete protocols like TLS 1.0. The practical takeaway is to fix in severity order: clear criticals to escape F, clear highs to escape C, then raise the average with headers. Note that clearing one high does not always lift the C cap — if two separate high findings exist, both must be resolved before the cap releases. Check the findings list rather than assuming a single fix moved you, then re-scan to confirm the cap has dropped.

How often should I re-scan?

Re-scan after every meaningful change rather than batching fixes together. Because the caps can hide the effect of individual fixes, a single re-scan after each step is the only reliable way to confirm a change actually moved the grade. Re-scan after clearing exposed files, again after fixing TLS, and again after adding headers. Batching several fixes and scanning once tells you the net result but not which change helped. Beyond active remediation, schedule a periodic scan — monthly is a sensible baseline — to catch regressions, such as a certificate that quietly expired or a backup file that got redeployed. Also re-scan right after any deploy, hosting change, or plugin update, since those are the moments a private file most often slips back into the web root. Treat the scanner as a continuous feedback loop, not a one-time audit, since configurations drift over time as code ships and infrastructure changes.

Related guides

See your whole external attack surface

One page is a start. The full external scan covers TLS, headers, DNS, exposed files, open services and known-exploited CVEs across your whole domain.

See the full scan →