A website security score gives you a single number that summarises how well your site is protected. This guide breaks down how the score is calculated, what the different ranges mean, and which fixes will move the needle fastest.
Anay Pandya
1,742 words
Anay Pandya
Founder of ZeriFlow · 10 years fullstack engineering · About the author
Key Takeaways
If you have ever run your site through a security scanner and received a number like 54/100 or 82/100, you have seen a website security score in action. But what does that number actually mean? How is it calculated? And which parts of your stack are dragging it down?
This guide answers all of those questions in plain language aimed at developers — not auditors. By the end you will know exactly what makes up a security score, where industry benchmarks sit, and which fixes give you the best return on time invested.
Is your site actually secure?
Run a free check — 60 seconds
Keep reading
A website security score is a single numeric value — usually expressed out of 100 — that represents the overall security posture of a web property at a given point in time. Think of it as a credit score for your site''s security hygiene.
The score is computed by running a battery of automated checks across multiple security categories, assigning a severity-weighted penalty for each failed check, and producing a final aggregated value. The higher the score, the fewer exploitable weaknesses your site exposes.
Scores are useful because security is not binary. A site is not simply "secure" or "insecure" — it exists on a spectrum, and the score gives you a way to:
Different tools weight their checks differently, but the underlying methodology is broadly similar. Here is how a rigorous scorer like ZeriFlow approaches it.
A full security scan covers multiple distinct domains. Each domain carries a maximum point contribution to the overall score:
| Category | What It Checks | Typical Weight |
|---|---|---|
| TLS / HTTPS | Certificate validity, TLS version, cipher suites | 20–25% |
| Security Headers | CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy | 20–25% |
| Cookies | Secure flag, HttpOnly, SameSite, expiry | 10–15% |
| DNS | DNSSEC, CAA records, zone exposure | 5–10% |
| Email Security | SPF, DKIM, DMARC | 10–15% |
| Content Security | Mixed content, open redirects, information disclosure | 10–15% |
| Privacy | Privacy policy, data transfer indicators, tracker exposure | 5–10% |
| Best Practices | Server version disclosure, directory listing, error page leakage | 5–10% |
Within each category, individual checks are flagged as Critical, High, Medium, or Low severity. A Critical failure (for example, an expired TLS certificate or no HTTPS at all) can alone drop your score by 20–30 points. A Low finding (for example, a missing X-Powered-By suppression header) might cost only 1–2 points.
This tiered model means your score gives you an implicit priority queue: fix the things that hurt most first.
The final score is typically calculated as:
score = Σ (check_weight × pass_factor) for all checksWhere pass_factor is 1.0 for a passing check, 0.0 for a failing critical check, and a partial value (e.g. 0.5) for checks that partially pass — such as HSTS being present but with a max-age that is too short.
Based on aggregated scan data across thousands of websites, here is roughly where sites land before deliberate hardening:
| Score Range | Interpretation |
|---|---|
| 0 – 39 | Critical — multiple severe vulnerabilities, immediate action required |
| 40 – 59 | Poor — common hardening steps have not been applied |
| 60 – 69 | Below average — some effort has been made but significant gaps remain |
| 70 – 79 | Average — meets basic security expectations; room for improvement |
| 80 – 89 | Good — strong posture; most common attack vectors are mitigated |
| 90 – 100 | Excellent — hardened configuration; only edge-case issues remain |
The uncomfortable truth is that the majority of production websites — including many that handle user data or payments — score between 40 and 65 before any explicit hardening work. This is not because developers are careless; it is because security configuration is not part of most default framework setups, and it rarely breaks the build when it is missing.
Expectations vary by context:
A site scoring around 60 typically has:
- Valid HTTPS, but no HSTS header
- No Content Security Policy
- X-Frame-Options either missing or set to ALLOWALL
- SPF record present but DMARC missing
- Cookies set without the SameSite attribute
This is a site where the developer remembered to get an SSL certificate but did not go further. It is vulnerable to clickjacking, certain XSS vectors, and protocol downgrade attacks.
A site at 70 has usually applied some headers — perhaps HSTS and X-Frame-Options — but has:
- A weak or overly permissive CSP (or none at all)
- Short HSTS max-age (below the recommended 1 year)
- Missing Permissions-Policy
- Referrer-Policy absent
- DMARC in monitoring mode (p=none) rather than enforcement
At 80, you have done meaningful hardening:
- HSTS with a reasonable max-age (≥6 months)
- A functional CSP that blocks inline scripts or at least reports violations
- All major headers present
- DMARC in enforcement (p=quarantine or p=reject)
- Cookies properly flagged
What is still missing might be HSTS preloading, a strict CSP with nonces/hashes, DNSSEC, or CAA records.
A 90+ score requires deliberate effort across every category:
- HSTS preloaded, includeSubDomains, max-age ≥ 1 year
- Strict CSP with ''nonce-...'' or ''strict-dynamic''
- Full DMARC enforcement with p=reject
- DNSSEC enabled and DANE configured
- CAA records limiting which CAs can issue certificates
- All cookies using Secure + HttpOnly + SameSite=Strict
- No server version disclosure anywhere
- Subresource Integrity (SRI) on third-party scripts
If you have just run your first scan and you are staring at a score of 55, here is the order in which to attack the issues:
If your site serves content over HTTP without a redirect to HTTPS, or if your certificate is expired or self-signed, fix this before anything else. This is the single largest contributor to a low score and the easiest to address — most hosting platforms and CDNs now offer one-click TLS via Let''s Encrypt.
The following headers are quick to add, require no application changes, and are accepted across all major browsers:
# Nginx example
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;Most sites have SPF set up. DMARC takes an extra 10 minutes and significantly raises your email security score:
_dmarc.yourdomain.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"If your application sets cookies, ensure every one of them has Secure, HttpOnly, and SameSite=Strict (or Lax where Strict would break cross-origin flows).
CSP is the most complex header to get right, but it is also the most powerful. Start in report-only mode to avoid breaking your site:
Content-Security-Policy-Report-Only: default-src ''self''; report-uri /csp-reportsThen tighten incrementally until you can switch to enforcement mode.
You can check your score manually using browser DevTools (Network tab → Response Headers) or purpose-built scanners:
For production applications, a one-off scan is not enough. You want continuous monitoring so that a deployment or DNS change does not silently drop your score. ZeriFlow''s monitoring feature runs daily or weekly scans and sends alerts via email, Slack, or Discord if your score drops below a threshold you define.
Once you have reached a score you are happy with, the goal is to maintain it. Integrating security scoring into your CI/CD pipeline ensures that a pull request cannot introduce a misconfiguration that would drop your score.
With ZeriFlow''s API, you can add a scan step to your pipeline:
# Example: block a deploy if score drops below 80
SCORE=$(curl -s "https://api.zeriflow.com/v1/scan?url=https://staging.yourdomain.com&token=$ZERIFLOW_API_KEY" | jq ''.score'')
if [ "$SCORE" -lt 80 ]; then
echo "Security score $SCORE/100 is below threshold. Deploy blocked."
exit 1
fi
echo "Security score $SCORE/100 — OK"This gives you a hard gate that prevents security regressions from making it to production.
"A high score means my site is secure." No. A score measures configuration hygiene. It does not test for application-level vulnerabilities like SQL injection, broken authentication, or logic flaws. Use a score as a baseline, not a certificate of security.
"I only need to check once." Your score can change any time your infrastructure changes — a new CDN config, a dependency update, a DNS record modification. Continuous monitoring is essential.
"Security scores are only for big companies." The opposite is true. Large companies have dedicated security teams. Individual developers and small SaaS teams are exactly who benefits most from automated, affordable security scoring tools.
A website security score is a practical, actionable metric that translates complex security configuration into a number you can track, benchmark, and improve. The key points to remember:
If you have not checked your score yet, run a free scan at ZeriFlow — it takes under 60 seconds and requires no account.
Related resources
Website Vulnerability Scanner
Run a broader website security audit across headers, TLS, DNS, cookies, SEO, and disclosure checks.
Security Headers Checker
Check CSP, HSTS, X-Frame-Options, and other response headers.
SSL Checker
Review TLS certificate, HTTPS, and transport security signals.
DMARC Checker
Validate email authentication records for domain spoofing protection.
CSP Checker
Review Content-Security-Policy coverage and common gaps.
April 30, 2026
Best SAST Tools for Small Development Teams in 2026 (Free Included)
Monitor your security score
Schedule recurring scans and catch regressions after deployments.