Website Security Headers: Fix Missing HSTS, CSP, and Frame Protection

Security headers are instructions your website sends to the browser. They do not clean malware, patch a CMS, or prove that a site is safe. They do reduce some common browser-side risks and help keep behavior predictable.

Headers worth knowing

For many small SaaS and business sites, these are the first headers to understand:

• Strict-Transport-Security, often called HSTS
• Content-Security-Policy, often called CSP
• X-Frame-Options
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy

Which ones are urgent

HSTS matters when your site should always use HTTPS. X-Frame-Options or a frame-ancestors CSP rule helps prevent clickjacking. X-Content-Type-Options helps browsers avoid guessing file types.

CSP can be powerful, but it needs care. A rushed CSP can break analytics, checkout, forms, or embedded assets. Start with reporting if the site is complex.

Headers can drift

Headers often change after CDN migrations, hosting changes, reverse proxy edits, or framework upgrades. A site that had good headers last month may lose them after a deployment.

How to use header checks

Use header checks as a public baseline. If a header disappears unexpectedly, investigate the deployment or proxy layer. If a new script domain appears at the same time, review whether it was intentional.

Do not stop at headers

Good headers are useful, but they do not replace server patching, access control, backups, dependency updates, and monitoring for public content changes.

Start with a small header baseline

A small business site does not need to copy every advanced security header from a large platform on day one. Start with a baseline that fits the site. HSTS for HTTPS, X-Content-Type-Options, Referrer-Policy, and frame protection are common first steps. CSP is valuable, but it needs testing because it controls where scripts, styles, images, frames, and forms can load from.

Why headers disappear

Headers can be set in many places: application code, web server config, CDN rules, hosting panels, reverse proxies, and security plugins. They can disappear during a hosting migration, CDN change, framework upgrade, or plugin replacement. That is why checking once is not enough for important sites.

Be careful with CSP

A strict CSP can block legitimate scripts, fonts, checkout widgets, analytics, maps, chat tools, and image CDN hosts. For a live site, test it carefully. Many teams start with a report-only policy, review violations, then move to enforcement once the policy matches reality.

Headers do not fix server compromise

Headers reduce browser-side risk and make some attacks harder. They do not remove malicious code, patch weak plugins, or protect exposed backups. Treat missing headers as a hardening issue unless they appear together with suspicious redirects, scripts, or content changes.

A sensible rollout order

Start with headers that are unlikely to break the site: X-Content-Type-Options, Referrer-Policy, frame protection, and HSTS when HTTPS is stable. Then evaluate Permissions-Policy. Save CSP for a careful rollout because it can block real assets if the policy is incomplete.

Document where each header is set. If a header is configured both in the app and at the CDN, future changes become confusing. One clear owner is easier to monitor and debug.

What to watch after header changes

Test login, checkout, analytics, embedded videos, fonts, forms, maps, and third-party widgets. If something breaks after a CSP change, the browser console usually shows the blocked source. Fix the policy intentionally rather than adding broad wildcards that remove most of the security value.

How to fix missing security headers

Choose one place to manage headers. For many small sites that is the web server or CDN. For application-heavy sites, some headers may be set in the app. Avoid setting conflicting values in multiple places because future debugging becomes difficult.

Add low-risk headers first: X-Content-Type-Options, Referrer-Policy, frame protection through X-Frame-Options or CSP frame-ancestors, and HSTS when HTTPS is stable across all subdomains you include. For CSP, start in report-only mode if the site has many third-party scripts.

Example CSP approach

A rushed CSP often becomes too loose or breaks production. Start by documenting required sources. Use report-only mode where practical. Tighten one directive at a time. Avoid broad wildcards unless there is a clear reason. For SaaS pages with checkout and analytics, test both authenticated and unauthenticated flows.