Security headers and score

1. What the security headers test does

The Security Headers section connects to your website over HTTPS (or HTTP if HTTPS fails), follows redirects and analyses the headers of the final response. This is usually the HTML of your home page.

For each important header, DNSprobe checks whether it is present, if its value looks safe and whether it follows current recommendations (for example use of HSTS, CSP, X-Content-Type-Options, Referrer-Policy, cookie flags, etc.).

The goal is not to give you a theoretical academic score, but a concrete view of how well your site protects visitors against common risks such as mixed content, clickjacking, MIME sniffing or cookie theft.

2. Understanding the score and grade

The score in DNSprobe goes from 0 to 100 and is converted to a letter grade from A to F. The points are distributed across several headers: some carry more weight (CSP, HSTS) while others are informational only.

An A does not mean your application is invulnerable; it simply indicates that your HTTP response headers are aligned with what is generally recommended today for a typical site.

Conversely, a low score does not automatically mean the site is insecure. Some applications deliberately relax certain policies (for example to allow iframes or broader cross-origin access). Use the score as a guide and always interpret it in the context of your project.

• A or B: headers are generally well configured. You may still refine CSP, permissions and reporting but the basics are in place.
• C or D: several important headers are missing or too permissive. It is worth reviewing the recommendations and gradually hardening your configuration.
• F: the server sends almost no security headers. This is common on legacy sites or default configurations, but it is strongly recommended to improve this before going live.

3. Key headers and what they do

Below is a quick summary of the most impactful headers analysed by DNSprobe and how they protect your visitors in concrete terms.

Some headers may be managed upstream by a reverse proxy, CDN or application server. What matters is the combination that finally reaches the browser.

4. Using the .htaccess template generated by DNSprobe

Below the table, DNSprobe generates an “optimal” .htaccess template based on Apache modules such as mod_headers and mod_rewrite. It includes realistic defaults for HSTS, CSP, frame protection, cookies, CORS and more.

This template is meant as a starting point. You should always review it, adapt the directives to your application and your stack (Apache, LiteSpeed, etc.) and deploy changes progressively, ideally in a staging environment first.

Some lines are intentionally commented out because they are more aggressive (for example strict CSP or automatic cookie rewriting). Enable them only once you understand the impact and have verified that your application continues to work correctly.

• If you already use a cache manager (LiteSpeed Cache, WP Rocket, reverse proxy, etc.), keep the HTML Cache-Control example commented and let your cache plugin control caching.
• Adjust CORS allow-lists and reporting endpoints to your own domains before enabling them in production.
• After deploying the template, re-run DNSprobe and check both the security headers score and the rest of the report (HTTPS, HSTS, mixed content, etc.).

The .htaccess template generated by DNSprobe is a starting point that you should adapt to your own stack (Apache, LiteSpeed, Nginx equivalents, CDN rules, reverse proxies, etc.) before deploying it to production.

5. Practical tips and common mistakes

Hardening HTTP headers is a gradual process. A few habits make it much easier to maintain over time:

• Start with non-breaking headers (HSTS on HTTPS-only sites, X-Content-Type-Options, Referrer-Policy) before introducing stricter CSP or Permissions-Policy rules.
• Test with your browser’s developer tools open and watch for blocked resources or CSP violations in the console.
• If you use a CDN or WAF, check whether it injects its own headers. Duplicated or conflicting directives can produce unexpected behaviour.
• Apply changes first on a staging environment or on a small subset of traffic, then roll out to production once you are confident.
• Document the rationale behind each header so future administrators understand what can safely be modified.

6. Limitations of automated header analysis

DNSprobe only analyses one URL: usually the home page of your site. Other paths (admin, APIs, download endpoints, legacy subdomains) may use different headers and should be tested separately if they expose sensitive data.

Some applications send dynamic headers depending on the user, the country or the device. In those cases, DNSprobe reflects only the behaviour of an anonymous request from its own point of presence.

Finally, no automated scanner can decide which exceptions are legitimate for your business. Use the report as a detailed checklist, then apply your own risk analysis to decide what to enforce or relax.

7. Test HTTP security headers manually from your own terminal

The Security Headers section in DNSprobe analyses the HTTP response headers returned by your site (HSTS, Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy, etc.) and gives you a score. You can inspect the same headers yourself from a terminal using curl against the HTTPS version of your site.

Linux: using curl to inspect response headers

On most Linux distributions, curl is installed or available in the default repositories. The following commands request only the HTTP response headers over HTTPS, so you can review all security-related headers returned by your server:

                curl -I https://example.com/
    
                # Quick overview of the status line and key headers (HSTS, CSP, X-Frame-Options, Referrer-Policy, etc.)    
                curl -s -D - -o /dev/null https://example.com/
        

macOS: using the built-in curl

macOS ships with curl as part of its standard command-line tools. Open Terminal and run the same commands as on Linux to see exactly which security headers your site is sending over HTTPS:

                curl -I https://example.com/
    
                # Quick overview of the status line and key headers (HSTS, CSP, X-Frame-Options, Referrer-Policy, etc.)    
                curl -s -D - -o /dev/null https://example.com/
        

Windows: using curl from Command Prompt or PowerShell

On modern versions of Windows 10 and 11, curl is included by default. From a Command Prompt or PowerShell window, you can use curl in the same way as on Linux/macOS to inspect your security headers:

                curl -I https://example.com/
    
                REM Quick overview of the status line and key headers (HSTS, CSP, X-Frame-Options, Referrer-Policy, etc.)    
                curl -s -D - -o nul https://example.com/
        

Important: only test hosts and domains that you own or are authorised to analyse. Repeated automated header checks against third-party systems without permission may be treated as abusive behaviour by some providers.