What does a website security score actually measure?

A website security score is usually a grade for settings a scanner can see from outside: HTTPS and redirects, HSTS, Content Security Policy, and cookie flags. It tells you how well the browser defenses are configured. It does not tell you whether the application has injection flaws or broken access control.

What goes into the score?

Tools differ and publish their own weights, so treat any number as that tool's opinion. What they share is a set of checks that the Mozilla Developer Network documents as good practice.

• HTTPS everywhere. All communication should use TLS, resources should load over HTTPS, and port 80 should only redirect to the same resource on HTTPS.
• HSTS. The Strict-Transport-Security header tells browsers to connect only over HTTPS. MDN recommends a max-age of at least six months, with two years suggested, and notes preload needs includeSubDomains and at least one year.
• CSP. Content Security Policy mainly reduces cross-site scripting damage and can limit framing through frame-ancestors.
• Cookie attributes. Secure, HttpOnly and SameSite limit how session cookies travel and who can read them.

Why can a site score well and still be vulnerable?

Because headers describe the container, not the code. MDN says CSP complements input sanitization and does not replace it. A page can have a strict policy and still contain an authorization flaw that lets one customer read another's records. No header can see that.

Constructed example: a booking site gets full marks for headers. Its invoice endpoint takes a numeric ID in the URL and never checks who owns the invoice. The score is high, and the data is open.

Can a low score be harmless?

Sometimes. A static brochure site with no login and no cookies has little to protect with cookie flags. A missing CSP there is a smaller problem than on an application with accounts. Read the failing checks and ask what an attacker would gain. Do not chase a perfect grade on a site where half the checks do not apply.

Which fixes are worth the effort first?

Start with the cheap ones that remove a whole class of problem.

1. Redirect HTTP to HTTPS on the same host, then enable HSTS with a short max-age and raise it as you gain confidence. Be careful with includeSubDomains since every subdomain must support HTTPS.
2. Set Secure, HttpOnly and SameSite on session cookies. MDN says session identifiers should always be HttpOnly.
3. Add a CSP in report-only mode using Content-Security-Policy-Report-Only, read the reports, then enforce. MDN describes this mode as reporting violations without blocking.
4. Add frame-ancestors to stop unwanted framing.

How to check or apply this

1. Run your site through a header and TLS scanner and save the raw output, not only the grade.
2. For each failure, write down the attack it would allow and whether your site is exposed.
3. Fix HTTPS, HSTS and cookie flags first.
4. Roll out CSP in report-only mode for two weeks.
5. Retest after each change, so you know which one moved the result.
6. Pair the score with the checks it cannot do: dependency scanning, code scanning and an authorization review.

Quick check

Sources

• MDN, TLS and HSTS implementation guidance
• MDN, Content Security Policy
• MDN, Cookies implementation guidance

Last reviewed: 18 October 2026.