Web Security Headers: What Each One Does and How to Set It

Security headers are among the cheapest defences available and among the easiest to deploy in a way that breaks a site. This guide covers what each does and how to roll out the difficult one safely, drawing on FISTA Solutions' web and mobile work.

Which headers matter?

A small set does most of the work.

Header	What it does
Content-Security-Policy	Restricts what may load and execute
Strict-Transport-Security	Forces HTTPS for future visits
X-Content-Type-Options	Prevents MIME type sniffing
Referrer-Policy	Controls referrer information sent
Permissions-Policy	Restricts browser feature access
frame-ancestors	Prevents framing by other sites

What does a content security policy actually protect against?

Execution of injected script. If an attacker manages to place script into your page, a policy that only permits scripts from your own origin prevents it running.

That is a meaningful defence in depth. It does not replace output encoding and input validation, and it catches the cases those miss.

It also restricts where the page may connect, which limits data exfiltration from an injected script that does manage to execute.

How should a policy be rolled out?

In report-only mode first, for long enough to see the full range of what the site loads.

Real sites load resources nobody documented: an analytics tag added for a campaign, an inline script in a template, a third-party widget that loads other third parties. A strict policy applied blind breaks them, frequently in ways that are not immediately visible.

Collect violation reports for a few weeks, tighten the policy against what you see, then enforce. Skipping the report-only period is how security header deployments cause outages.

What makes policies hard to tighten?

Inline scripts and styles, and third parties that load further third parties.

Inline content requires either hashes, nonces, or an unsafe allowance that weakens the policy substantially. Nonces are the better answer and require server-side generation per request.

Third parties that load additional resources dynamically are the harder problem, because you cannot enumerate what they will fetch. That is a reason to limit them independently of the policy.

What about transport security?

Strict transport security tells browsers to use HTTPS for future visits, which prevents downgrade attacks.

The care needed is around subdomains and preload. Including subdomains commits every subdomain to HTTPS, and preload submission is difficult to reverse. Both are correct for most sites and worth confirming before enabling.

Start with a short max-age, confirm nothing breaks, then extend. A long max-age set incorrectly locks visitors out of a misconfigured subdomain for the duration.

What about the simpler headers?

Content type options, referrer policy, and permissions policy are close to free and worth setting.

Content type options prevents the browser guessing types, which closes a class of attack. Referrer policy controls what information leaves with outbound requests, which matters for privacy as well as security. Permissions policy restricts access to browser features the site does not use.

Set sensible defaults for all three in one change. There is rarely a reason not to.

Where should headers be set?

As close to the edge as is practical and consistently across every response.

Headers set in application code get missed on error pages, static assets, and responses from other layers. Setting them at the edge or in the gateway covers everything uniformly.

Verify across response types rather than checking the home page. Error pages and asset responses are the ones most often missed. See CDN strategy guide.

What are the common mistakes?

Enforcing a policy without report-only first. Allowing unsafe inline to make the policy work. Long transport security max-age before verifying. Headers set only in application code. And not collecting violation reports.

How do you test it?

Check headers across response types including errors and assets, verify the policy in report-only mode with real traffic, and test that violation reports are being received.

Automated header checks in the pipeline prevent a deployment silently dropping them, which happens when infrastructure changes.

What does it cost to operate?

Close to nothing to operate. The cost is the engineering time to tighten a content security policy against an existing site, which for a site with many third parties can be substantial.

New sites can adopt a strict policy from the start at almost no cost, which is a strong argument for doing it then.

What should you measure?

Policy violation reports by directive and source, header presence across response types, and whether the policy still permits anything unsafe.

What about AI features and policy?

Model provider connections need permitting in the connect directive, and any client-side SDK needs its sources allowed.

The better pattern is keeping model calls on the server, which keeps both the credentials and the policy simpler. A client calling a provider directly needs its origin permitted and exposes the key, and neither is desirable.

When is this the wrong approach?

There is no context where these headers are wrong. There are policies too strict for a given site, which is what report-only mode exists to discover.

What should you do first?

Deploy a content security policy in report-only mode and collect violations for two weeks. What you find is usually surprising and it scopes the whole exercise.

How FISTA Solutions helps

FISTA Solutions builds and operates production systems through web and mobile, AI enablement, and staff augmentation: content security policies rolled out in report-only mode before enforcement, headers set at the edge so every response carries them, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To scope this work, message FISTA on WhatsApp, or read authentication architecture guide.