Test Your HTTP Security Headers and Copy the Fixes

Security headers are instructions your server sends with each response that tell browsers how to protect your visitors: always use HTTPS, don’t run scripts from unknown sources, don’t let other sites frame this page, don’t leak full URLs to third parties. They cost nothing to add and close off entire classes of attacks.

This security headers checker requests your page and grades it from A+ to F on Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy and the flags of any cookies it sets. For every missing or weak header, you get a copy-paste fix for Apache, Nginx and Cloudflare.

How to check your security headers

1. Enter a page URL

   Start with your home page, then test a login or checkout page, where cookies and strict policies matter most.

2. Review the grade

   See which headers are present, which are missing or weak, and how each one affects the overall grade.

3. Apply the fixes

   Copy the snippet for your server or CDN, deploy it, purge caches and run the check again.

What each security header does

Header	Protects against	Good starting value
Strict-Transport-Security	Downgrades to HTTP, cookie theft on open Wi-Fi	max-age=31536000; includeSubDomains
Content-Security-Policy	Cross-site scripting, injected scripts	A tailored allow-list, tested in Report-Only mode first
X-Content-Type-Options	MIME-type sniffing	nosniff
X-Frame-Options	Clickjacking	SAMEORIGIN or DENY
Referrer-Policy	Leaking full URLs to other sites	strict-origin-when-cross-origin
Permissions-Policy	Unwanted camera, microphone or location access	camera=(), microphone=(), geolocation=()
Set-Cookie flags	Session theft, cross-site request forgery	Secure; HttpOnly; SameSite=Lax

X-XSS-Protection is obsolete; modern browsers ignore it, and MDN recommends relying on CSP instead. CSP’s frame-ancestors directive is the modern replacement for X-Frame-Options, and sending both is fine. Background: security headers and HSTS.

Copy-paste configuration

Apache (virtual host or .htaccess, with mod_headers):

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Nginx (in the server block):

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Nginx gotcha: a location block with its own add_header drops every header inherited from the server block, so repeat them there or use an include file. The always flag sends them on error pages too.

Cloudflare: enable HSTS under SSL/TLS → Edge Certificates, and add the other headers with a response header Transform Rule (Cloudflare docs).

Rolling out a Content Security Policy safely

CSP is the most powerful header and the easiest one to break a site with, because it blocks every script, style, font or frame source you didn’t list. Start in report-only mode, which logs violations without blocking anything:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; frame-ancestors 'self'; report-uri /csp-reports

Watch the browser console and your report endpoint for a week or two, add the sources you really use, then rename the header to Content-Security-Policy. Prefer nonces or hashes for inline scripts over 'unsafe-inline'; MDN’s CSP guide documents every directive.

Do security headers affect SEO?

Not directly: Google doesn’t use CSP or X-Frame-Options as ranking signals, and HSTS simply makes sure returning visitors land on your HTTPS version. The indirect stakes are real, though. A hacked site with injected spam or malware can trigger browser warnings and a “This site may be hacked” label in search results, and cleaning that up costs far more traffic than the headers ever could. Check the certificate side with the SSL checker.

Tips for rolling out security headers

• Set headers at one layer, the server or the CDN, so you don’t end up with duplicate or conflicting values.
• Start HSTS with a short max-age such as 300 seconds, confirm every subdomain works over HTTPS, then raise it to a year.
• Only add the preload directive and submit to hstspreload.org once you are sure every subdomain will stay on HTTPS; removal takes months.
• Set Secure, HttpOnly and SameSite on session and login cookies in your application or framework settings.
• Re-test after CMS, plugin or CDN changes, which can add, remove or overwrite headers.

Limits to keep in mind

The grade reflects the headers and cookies returned for the URL you test, without logging in. Other pages, file types and logged-in areas can send different headers, so test the ones that matter. A good grade isn’t a security audit: we don’t scan for vulnerabilities, outdated software or weak access control. For a second opinion, Mozilla’s HTTP Observatory is a good reference, and the HTTP header checker shows the full raw response.

Last updated Oct 30, 2026 by the Yes SEO team.