Security headers: the underrated website check for browser protection

Many website projects only look at security when something visibly breaks: login fails, form spam explodes, a plugin vulnerability appears, or a client asks for a security scan. But there is a quieter baseline that should be checked much earlier: HTTP security headers.

Security headers are not a firewall and they do not replace clean code. But they give the browser clear rules: which sources may load scripts, whether the site should always use HTTPS, how much referrer information is sent to external services, and whether the page may be embedded in other sites.

OWASP describes HTTP headers as an easy-to-implement booster for web security. MDN documents, among other things, that Content Security Policy can restrict loaded resources and help guard against cross-site scripting, HSTS tells browsers to use HTTPS for future requests, and Referrer-Policy controls how much referrer information is sent with requests.

Why headers belong in website audits

For small business sites, WordPress projects, SaaS landing pages, and agency builds, headers are often split across hosting, CMS, CDN, framework, and reverse proxy. That is where gaps appear:

• The CDN sets HSTS, but the staging domain breaks.
• The framework sets default headers, but the reverse proxy overwrites them.
• A cookie banner or chat widget needs external scripts and the CSP is opened too widely.
• Referrer-Policy is missing and campaign URLs with parameters are unnecessarily sent to third parties.
• X-Powered-By exposes framework details without benefit.
• Old headers such as X-XSS-Protection are copied blindly, even though modern guidance usually focuses on CSP instead.

The problem is rarely one missing header. The problem is that nobody knows which layer controls them.

The practical minimum check

A website check should not just paste an online scanner score. A better audit is small and reproducible:

1. Test production: which headers are delivered on the homepage, subpages, login, forms, and checkout?
2. Check redirects: does HTTP reliably redirect to HTTPS? Are headers set after the final redirect?
3. Review CSP honestly: is there a real policy, or mostly unsafe-inline and wildcards?
4. Roll out HSTS carefully: test with a short duration first; use long durations and subdomains only when certificates and subdomains are under control.
5. Set Referrer-Policy: for many sites, strict-origin-when-cross-origin is a useful starting point.
6. Prevent MIME sniffing: use X-Content-Type-Options: nosniff and serve correct content types.
7. Control embedding: use CSP frame-ancestors if pages should not be embedded elsewhere.
8. Review caching for sensitive pages: login, account, checkout, and internal areas need different rules from public assets.

CSP without self-destruction

Content Security Policy is powerful, but it is also the header most likely to break a site. A policy that is too strict can break forms, payments, tracking, videos, or consent banners. A policy that is too loose looks good but protects little.

A safer rollout looks like this:

• Inventory external scripts, styles, images, frames, and APIs.
• Start with Content-Security-Policy-Report-Only.
• Collect violations and decide deliberately what must be allowed.
• Enforce gradually.
• Treat every new third-party integration as a CSP change.

For agencies, this is a useful handover point. If a client later adds a new tracking pixel, it should be clear that this is not only marketing work. It changes security configuration too.

Headers as maintenance

Security headers are not a one-time ticket. They change with hosting, CDN, framework, plugins, and third-party tools. They belong in maintenance:

• Recheck after relaunches or hosting migrations.
• Compare headers after CDN or proxy changes.
• Test CSP after new form, payment, chat, or tracking tools.
• Run a header scan once per quarter.
• Document header ownership in the repository or operations handbook.

Conclusion

HTTP security headers are boring in the best way. They do not make a landing page prettier and they do not sell the product. But they reduce unnecessary attack surface, protect users, and show whether a website team controls its infrastructure. A good website check should therefore review not only plugins, performance, and cookie banners, but also the headers the browser actually receives.

Sources

• OWASP Cheat Sheet Series: HTTP Security Response Headers
• MDN: Content-Security-Policy (CSP) header
• MDN: Strict-Transport-Security header
• MDN: Referrer-Policy header

Note: This article is a technical overview and does not constitute legal advice.