ServerRecords

Help & Troubleshooting

Security Headers

What this is

A handful of HTTP response headers instruct browsers to enable protections: HSTS (force HTTPS), CSP (restrict resource loading), X-Frame-Options (block framing), X-Content-Type-Options (block MIME sniffing), Referrer-Policy, and Permissions-Policy.

How to read your result

Each header is reported present or missing with what it protects against. Missing headers are opportunities, not outages — but they are among the cheapest security wins available.

Common problems and how to fix them

Most or all security headers missing

How it shows up: Nothing visibly breaks, but the site is needlessly exposed to clickjacking, MIME confusion, and referrer leakage; scanners grade it poorly.

How to fix it: Add them at the web server or CDN level. Safe starters for almost any site: X-Frame-Options: DENY (or SAMEORIGIN), X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, plus HSTS.

Adding a strict Content-Security-Policy broke the site

How it shows up: Scripts, styles, or images stop loading; the console fills with CSP violation errors.

How to fix it: Roll CSP out in report-only mode first (Content-Security-Policy-Report-Only) and tighten iteratively based on the violation reports, then switch to enforcing once clean.

Headers set in the app but stripped in production

How it shows up: Local testing shows the headers; the live site lacks them.

How to fix it: A proxy/CDN layer in front is overwriting or dropping them. Set the headers at the outermost layer that terminates the connection (usually the CDN), or configure it to pass origin headers through.

Run a look up for this record