The most common security header mistakes are: a permissive Content-Security-Policy (or one with unsafe-inline), setting HSTS with preload before you are ready, duplicated or conflicting headers, headers set on some responses but not others, and copy-pasted policies that break functionality. Each weakens protection or breaks the site.
Security headers are powerful but easy to misconfigure. A policy that looks present may be doing nothing — or quietly breaking pages. This guide covers the mistakes we see most often and how to get each header right across your whole site.
Check your website
See how your site handles common security header mistakes (and how to avoid them) — free, no account needed.
For business owners
Misconfigured security headers give a false sense of protection: the header is there, but it is not actually defending you — or it is blocking legitimate content and costing you customers. Getting them right closes real gaps and avoids self-inflicted outages, which is exactly what a trust scan surfaces.
How it works (technical)
Frequent problems and fixes:
- Weak CSP — using
unsafe-inline/unsafe-evalor overly broad sources defeats the point; use nonces/hashes and tight allowlists. - Premature HSTS preload — adding
preloadbefore all subdomains are HTTPS can lock users out; rampmax-agefirst. - Inconsistent coverage — headers on the homepage but not on APIs, error pages or subdomains.
- Duplicated/conflicting headers — set by both the app and the CDN, producing undefined behaviour.
- Copy-paste policies — pasting someone else's CSP and breaking scripts, styles or widgets.
- Deprecated headers — relying on
X-XSS-ProtectionorFeature-Policyinstead of CSP andPermissions-Policy.
Test with a header scanner and your browser console, and roll out CSP in report-only mode first.
Real-world example
A team deployed a strict CSP copied from a blog post. It blocked their analytics and payment widget, and checkout broke. Rolling back, switching to Content-Security-Policy-Report-Only, fixing the allowlist, then enforcing it delivered strong protection without the outage.
Why it matters
Header mistakes either leave you exposed or break your site. Scanners flag missing and misconfigured headers so you can fix them deliberately rather than discovering issues in production.
How to fix it
Roll out CSP in
Content-Security-Policy-Report-Onlyfirst, then enforce.Replace
unsafe-inlinewith nonces or hashes and tighten source allowlists.Increase HSTS
max-agegradually and only addpreloadonce every subdomain is HTTPS.Apply headers consistently across all pages, APIs, error pages and subdomains.
Ensure headers are set in one place (app or CDN, not both) to avoid conflicts.
Drop deprecated headers in favour of CSP and Permissions-Policy.
Best practices
Test every header with a scanner and the browser console before and after changes.
Prefer report-only phases for CSP to catch breakage safely.
Document where each header is set to prevent duplication.
Common mistakes
Shipping a CSP with unsafe-inline that provides little real protection.
Adding HSTS preload prematurely and locking out non-HTTPS subdomains.
Setting headers in both the app and the CDN, causing conflicts.
Applying headers only to the homepage, leaving other routes exposed.
Frequently asked questions
Why is my CSP not protecting me?
Often because it includes unsafe-inline or overly broad sources, which permit exactly what CSP is meant to block. Use nonces/hashes and tight allowlists.
Is HSTS preload safe to enable immediately?
No. Preload is hard to reverse. Ensure every subdomain is HTTPS and ramp max-age first, then submit to the preload list.
Can duplicate headers cause problems?
Yes. If your app and CDN both set a header, the result can be conflicting or undefined. Set each header in exactly one place.
Should I copy a CSP from another site?
Not directly. CSPs are specific to a site's scripts and services. Start from your own inventory and test in report-only mode.
Are X-XSS-Protection and Feature-Policy still used?
They are deprecated. Use Content-Security-Policy for XSS mitigation and Permissions-Policy in place of Feature-Policy.
Do headers need to be on every page?
Yes for consistent protection. Applying them only to the homepage leaves APIs, error pages and other routes exposed.
How do I test security headers?
Use a header-scanning tool and your browser console, and roll out CSP in report-only mode to catch breakage before enforcing.
What is the safest way to deploy a strict CSP?
Report-only first, review violation reports, fix legitimate sources, then switch to enforcing mode.
Put this into practice
See how your site scores with Plexa Trust — start with a free scan, then unlock the complete audit on Pro.
Scan your website free