SSL & HTTPS
Security Headers & HSTS
Check the values that shape browser protection.
NEXT STEPS
Where to configure response headers
Review existing headers first. Test changes on representative pages before applying them broadly.
Nginx example
add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; # In your HTTPS server block, after HTTPS is reliable: add_header Strict-Transport-Security "max-age=86400" always;
Begin with a short HSTS lifetime. Add includeSubDomains only when all subdomains support HTTPS. CSP needs an application-specific source list.
Apache example
Header always set X-Content-Type-Options "nosniff" Header always set Referrer-Policy "strict-origin-when-cross-origin" # In the HTTPS virtual host only: Header always set Strict-Transport-Security "max-age=86400"
These directives require mod_headers. Check for duplicate headers set by a proxy or CDN.
WordPress deployments
Set site-wide headers in the web server or CDN when possible, so cached pages and static assets are covered. A plugin affects only responses it handles. Test login, admin, forms and embedded services before restricting CSP or framing.
UNDERSTAND THE RESULT
What this check tells you
Presence alone is not proof of protection. Findings inspect values and explain their context; there is no artificial security score. CSP Report-Only does not enforce a policy. HSTS is effective only over HTTPS and preload requires inclusion in browser lists.
Reference: MDN HTTP headers ↗
A snapshot, with context
Every report includes its check time. DNS caches, CDN edges and server configuration can change. Repeat a check after a fix and compare the actual records or responses.
Read the methodology ↗