Website Security Headers: What They Protect and How to Review Them

Website security headers are small instructions sent with a web page response. They tell browsers how to handle scripts, frames, transport security, referrer data and powerful browser features. They will not fix vulnerable code or remove malware, but they can reduce the damage from several common web security mistakes.

The useful question is not whether a scanner shows a perfect score. The better question is whether each header matches the way your website actually works. A WordPress site with forms, analytics, embedded videos and admin pages needs a different review than a simple static brochure site or a Laravel application with a customer portal.

Start with the page types that matter

Review headers on the pages where risk is highest: login screens, checkout pages, quote forms, account pages, admin routes and pages that load third-party scripts. A header set on the homepage may not be present on every response, especially when a site uses a mix of application routes, cached pages, uploads, CDN rules and server redirects.

Create a short sample list before making changes. Include the public homepage, one service page, the quote form, a blog post, the login page, a 404 page and any separate dashboard area. If the site uses both www and non-www hostnames, test both final HTTPS destinations.

This keeps the review practical. It also avoids a common mistake: adding a strict setting to one visible page while sensitive areas keep older behavior.

Content Security Policy controls where content can load from

A Content Security Policy, usually called CSP, lets a site restrict where scripts, images, fonts, frames and other resources may be loaded from. MDN's Content Security Policy guide explains that CSP is designed to help prevent or reduce the impact of attacks such as cross-site scripting and data injection.

A useful CSP is specific. It should reflect the real domains used by your website: analytics, payment providers, font sources, image CDN, reCAPTCHA, chat widgets and embedded media. A policy that allows everything from everywhere offers little protection. A policy that blocks needed resources can break forms, maps, videos or dashboards.

For an existing site, start in report-only mode where appropriate, collect violations and tighten the policy in stages. Do not copy a strict CSP from another website and deploy it directly to production without testing the actual pages your visitors use.

HSTS helps browsers stay on HTTPS

Strict-Transport-Security, often shortened to HSTS, tells browsers to use HTTPS for future requests to a domain after a secure response has been received. MDN's HSTS reference notes that the header is sent over HTTPS and affects future browser connections.

HSTS is powerful because it changes browser behavior. Before enabling it with long durations or includeSubDomains, confirm that every required subdomain works reliably over HTTPS. This matters for businesses using separate portals, old campaign subdomains, staging hosts, mail tracking links or third-party services under the same domain.

Do not enable HSTS preload casually. It can be valuable for mature HTTPS setups, but it requires confidence that the domain and covered subdomains are ready to stay HTTPS-only.

Frame protection reduces clickjacking risk

Clickjacking happens when a site is placed inside another page in a way that tricks users into interacting with it. The older X-Frame-Options header and the newer CSP frame-ancestors directive can help control whether a page may be embedded. MDN documents X-Frame-Options as a response header used to indicate whether a browser should allow a page to be shown in a frame.

For most public websites, preventing unauthorized framing is sensible. But some sites intentionally embed dashboards, booking tools, support widgets or payment flows. Those cases need a planned allowlist rather than a blanket rule that breaks legitimate workflows.

Test forms and login pages especially. They are attractive targets and also the places where embedded third-party features are most likely to exist.

Referrer-Policy controls how much URL information is shared

When a visitor clicks from your site to another site, the browser may send referrer information. MDN's Referrer-Policy reference explains that this header controls how much referrer information should be included with requests.

This is not only a privacy setting. URLs sometimes contain campaign data, search filters, account paths or accidental identifiers. A practical default can reduce unnecessary sharing while preserving analytics that the business actually needs.

Review whether full URLs are needed outside the site. For many sites, a stricter policy can still support normal measurement without exposing complete paths to every destination.

Permissions-Policy limits browser features

Permissions-Policy lets a site control access to browser features such as camera, microphone, geolocation and other APIs. MDN's Permissions-Policy reference describes it as a mechanism for allowing or denying feature use in a document or embedded content.

A simple company website usually does not need camera, microphone or geolocation access. A support portal, video consultation tool or store locator may need some of those features. The policy should match the features the site intentionally uses.

Blocking unused features can reduce unnecessary exposure and improve user trust, but it should be reviewed before launch if the site includes embedded tools controlled by third parties.

Use scanners carefully

Security-header scanners can be useful for discovery, but a high score is not the same as a secure site. The OWASP HTTP Headers Cheat Sheet lists recommended headers and explains several deprecated or risky headers as well. That context matters because adding obsolete headers can create a false sense of progress.

When reviewing a scanner report, separate missing headers from broken policies. A missing header is a configuration gap. A present header with unsafe values may need more careful work. A strict header that breaks checkout or login is also a problem, even if the scanner likes it.

Keep a change record. Note which header was changed, where it is set, which pages were tested and how rollback would work.

Where headers are configured

Headers can be configured in more than one place. Depending on the site, they may live in the web server, CDN, hosting panel, Laravel middleware, WordPress security plugin, reverse proxy or application code. Multiple layers can overwrite each other.

For example, a CDN may add HSTS, the application may add CSP, and the server may add frame options. If two policies conflict, browsers follow the actual response they receive, not the intent written in a project note. Always check the final public response.

Use separate settings for static assets and HTML pages when needed. Images and downloadable files do not always need the same policy as an interactive page.

How to review headers without breaking the site

• Inventory important pages: homepage, forms, login, admin, checkout, blog, error pages and dashboards.
• Record current headers: save the actual response headers before changing anything.
• Map third-party services: analytics, fonts, video embeds, payment, chat, CAPTCHA and tag managers.
• Start with safe improvements: avoid jumping straight to long HSTS preload or strict CSP enforcement.
• Test workflows: submit forms, sign in, load embeds, complete checkout and check browser console errors.
• Monitor after release: watch support messages, CSP reports, analytics changes and form failures.

If you need help reviewing a live site, send MaxMindSecurity the domain, platform, hosting or CDN provider and any scanner report through the contact page. For broader protection planning, compare headers with our website security layers guide.

Editorial note: this article was prepared with AI assistance and reviewed against the linked Google, OWASP and MDN documentation. It is educational guidance, not a guarantee that any specific header set will prevent every attack or improve rankings. The featured image is an AI-generated security operations illustration from the site's existing media library.