Security Headers Score: What It Means and How to Improve It

What is a security headers score?#

A security headers score is a numeric assessment of how well a website's HTTP response headers protect against common web attacks. HTTP response headers are small instructions that a web server sends alongside every page it delivers. Most of these headers handle routine tasks like caching and content type declarations, but a specific group of them exists purely for security. These security headers tell the browser what it should and should not allow when rendering a page.

Scanners evaluate whether those headers are present, whether they are configured correctly, and how they interact with the broader security posture of the site. The result is typically a letter grade. An A+ means the site has strong, well configured headers across the board. An F means most or all protective headers are missing. Grades in between reflect partial coverage or headers that are present but misconfigured.

The score is not a guarantee of security. It measures one layer of defense. But it is an important layer because security headers close attack paths that exist entirely at the browser level, where application code cannot intervene. A site with strong authentication and input validation but no security headers still leaves its visitors exposed to attacks like cross-site scripting (where malicious scripts run in the user's browser) and clickjacking (where an attacker loads your page inside an invisible frame to trick visitors into clicking hidden buttons).

What factors affect your score#

A security headers score is not simply a count of how many headers are present. The assessment looks at multiple dimensions of your site's security posture. Some headers matter more than others, and how a header is configured can be just as important as whether it exists at all.

The main areas that influence your score include:

• Presence of key headers: Whether the most important security headers appear in your server's HTTP response at all. Missing headers are the most common finding on most websites.
• Configuration quality: A header that is present but poorly configured can be worse than no header. For example, a Content-Security-Policy that allows all inline scripts offers almost no protection against cross-site scripting despite being technically present.
• CSP policy strength: Content-Security-Policy is evaluated in detail because it is the single most impactful security header. The strictness of its directives, whether it uses nonces or hashes instead of unsafe keywords, and how narrowly it scopes allowed sources all factor in.
• TLS and transport security: Your site's TLS configuration, including certificate validity, protocol version, and whether HSTS enforces encrypted connections, contributes to the overall assessment.
• Cookie security attributes: Cookies set without the HttpOnly, Secure, or SameSite attributes are vulnerable to theft and misuse. These flags are evaluated alongside headers because they are part of the same HTTP response.

DNS security records such as SPF (which controls who can send email from your domain), DMARC (which tells receivers how to handle messages that fail authentication checks), and DNSSEC (which protects DNS responses from tampering) can also factor into a comprehensive security assessment. These sit outside the HTTP response itself but are part of the same trust chain that protects your visitors.

The headers with the biggest impact#

Not all security headers carry equal weight. The headers below have the greatest influence on your score because they address the most common and most damaging attack vectors on the modern web.

Content-Security-Policy (CSP)

CSP is the single most impactful security header. It defines a policy that tells the browser exactly which resources are allowed to load on your page: scripts, stylesheets, images, fonts, frames, and more. Anything not explicitly permitted is blocked. This directly prevents cross-site scripting (XSS), the most widespread web vulnerability, by ensuring that only scripts you have approved can execute in your visitors' browsers.

Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'"

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'" always;

Strict-Transport-Security (HSTS)

HSTS tells browsers to only connect to your site over HTTPS. Once a browser sees this header, it will automatically convert any HTTP request to HTTPS before sending it, eliminating the window where an attacker on the same network could intercept or modify the initial unencrypted request. This prevents protocol downgrade attacks and SSL stripping.

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

X-Content-Type-Options

This header prevents MIME sniffing, a behavior where the browser ignores the declared content type of a file and tries to guess what it is by examining the contents. Without this header, a browser might treat a text file or uploaded image as executable JavaScript if the file contents resemble a script. Setting this header to nosniff is a single line of configuration with no risk of side effects.

Header always set X-Content-Type-Options "nosniff"

add_header X-Content-Type-Options "nosniff" always;

X-Frame-Options

X-Frame-Options controls whether your page can be embedded in an iframe on another site. Setting it to DENY or SAMEORIGIN prevents clickjacking attacks, where an attacker loads your page inside an invisible frame and tricks visitors into interacting with it unknowingly.

Referrer-Policy and Permissions-Policy

Referrer-Policy controls how much of the current page URL is shared with third parties when a visitor clicks a link or when an external resource loads. Without it, the full URL of every page, including potentially sensitive path segments and query parameters, is sent to every external origin. Permissions-Policy limits which browser features and APIs, such as the camera, microphone, and geolocation, your page and its embedded iframes are allowed to use. Both headers carry less weight individually but contribute meaningfully to a comprehensive security posture.

How to improve your score step by step#

Improving your security headers score does not require a complete infrastructure overhaul. Most sites can move from a D or F to a B within a single focused session. Getting to an A or A+ takes more care, especially around Content-Security-Policy, but the process is straightforward if you approach it methodically.

Step 1: Run a scan to get your baseline

Before making changes, scan your site to see exactly which headers are present, which are missing, and which are misconfigured. This gives you a clear starting point and a prioritized list of findings. SiteSecurityScore provides a free scan that covers all major security headers, TLS configuration, cookie attributes, and DNS security records.

Step 2: Add missing headers one at a time

Rather than trying to add everything at once, work through your findings individually. Add one header, deploy, and verify it appears in the response before moving to the next. This makes it easy to identify the cause if something breaks.

Step 3: Start with low risk headers

Some headers are safe to add on any site with virtually no risk of breaking functionality. X-Content-Type-Options: nosniff and Referrer-Policy: strict-origin-when-cross-origin are good starting points. X-Frame-Options: DENY is also safe unless your site is intentionally embedded in iframes on other domains.

Step 4: Tackle Content-Security-Policy

CSP has the biggest impact on your score but is also the most complex header to configure. Start with Content-Security-Policy-Report-Only mode, which logs violations without blocking anything. Review the reported violations to understand which resources your page loads and from where. Once you have a policy that covers all legitimate sources, switch from report-only to enforcement mode. See the Content Security Policy guide for a detailed walkthrough.

Step 5: Re-scan to verify improvements

After adding or updating headers, run another scan to confirm the changes are live and correctly configured. It is common for headers to be set in the application but stripped by a CDN, load balancer, or reverse proxy before reaching the browser. The scan result tells you exactly what the browser sees, not what your server configuration file says.

Common mistakes that lower your score#

Some of the most frequent issues found in scans are not about missing headers. They are about headers that are present but configured in a way that undermines their purpose.

• Using unsafe-inline and unsafe-eval in CSP: These directives allow inline scripts and dynamic code evaluation, which effectively disables the cross-site scripting protection that CSP is designed to provide. A policy that includes these keywords may look complete but offers minimal real protection.
• Missing HSTS on subdomains: Setting Strict-Transport-Security on your main domain but omitting the includeSubDomains directive leaves subdomains exposed to protocol downgrade attacks. Attackers can target a subdomain to steal cookies scoped to the parent domain.
• Cookie flags not set: Cookies missing the HttpOnly flag can be read by JavaScript, making them vulnerable to theft through XSS. Cookies without the Secure flag can be sent over unencrypted connections. Missing SameSite attributes leave cookies vulnerable to cross-site request forgery.
• Headers set in HTML meta tags instead of HTTP response: Some headers like Content-Security-Policy can technically be set via HTML meta tags, but meta tag headers are applied later in the page lifecycle and do not cover all directives. Headers must be set in the actual HTTP response to be fully effective.
• Duplicate or conflicting headers: When the same header is set in multiple places, such as the application, the web server, and the CDN, the values can conflict or override each other in unexpected ways. This often results in a weaker effective policy than any single configuration intended.

For a deeper look at these issues and how to resolve them, see the guide on why your security headers are not working.

Monitoring your score over time#

Fixing your security headers once is not enough. Security headers can disappear or change without anyone making a deliberate decision. Deployments can overwrite server configuration files. Certificate renewals can fail silently. CDN updates can reset edge rules. Platform migrations can introduce new middleware that strips headers from responses.

These regressions are common because security headers live in configuration rather than application code. They are not covered by unit tests or code reviews. A change to your infrastructure can remove protections that took hours to set up, and unless someone scans the site after the change, the gap goes unnoticed.

The best defense against silent regressions is automated monitoring. Daily automated monitoring scans your site on a schedule and alerts you the moment something changes. Instead of relying on memory or manual checks after every deploy, you receive a notification when a header is removed, a certificate approaches expiry, or a cookie flag disappears.

At minimum, run a scan after every deployment and infrastructure change. For most teams, setting up daily monitoring eliminates the risk entirely and takes less than a minute to configure.

FAQ#