Website Security Headers

Information checked: 21 July 2026.

HTTP security headers instruct browsers to apply restrictions that can reduce selected web risks. They are useful defence in depth, but incorrect settings can break scripts, payments, embedded services or downloads.

In brief: Use a tested CSP and a small set of appropriate headers, not an unverified checklist pasted into server configuration.

Prioritise modern controls

Common security headers

Header	Purpose	Deployment note
Content-Security-Policy	Restricts permitted resource and framing sources	Begin with inventory and reporting before enforcement
Strict-Transport-Security	Tells browsers to use HTTPS for the host	Enable only after HTTPS works reliably on required subdomains
X-Content-Type-Options	Prevents selected MIME-type guessing	Usually use nosniff
Referrer-Policy	Controls referral information sent to other sites	Choose according to analytics and privacy needs
Permissions-Policy	Limits selected browser features	Test functions that use camera, location or payment features

Deploy CSP safely

1. Inventory scripts, styles, frames, fonts and network destinations.
2. Remove unused third-party resources.
3. Start with Content-Security-Policy-Report-Only where appropriate.
4. Review violations and distinguish required resources from unsafe exceptions.
5. Move towards nonces or hashes instead of broad unsafe-inline rules.
6. Enforce in stages and test every customer journey.

Avoid outdated cargo-cult settings

Do not copy a header block without understanding it. Some older headers are obsolete or superseded, and a permissive CSP that allows every source may provide little practical protection.

Acceptance check

Inspect headers on representative HTML, asset, error and authenticated responses. Test login, forms, payments, media and embedded content after enforcement.

Treat third-party scripts as dependencies

A CSP often reveals how many marketing, support and embedded services a page loads. Instead of allowing every reported domain, confirm who owns each dependency and whether it is still required. Remove obsolete resources before broadening the policy.

Records to keep

• Resource and origin inventory.
• Report-only violation review.
• Approved policy and rollback configuration.
• Test results for embedded and transactional features.

Owner test: Open representative pages with browser developer tools and explain every external script or frame allowed by the final policy.

Sources and date checked

This practical guidance was checked against the following primary sources. Date checked: 21 July 2026.

• OWASP: HTTP Security Response Headers Cheat Sheet
• MDN: Content Security Policy
• MDN: Web security guidance