Security headers tell browsers how to handle content, transport, embedding, referrers, and selected capabilities. They are valuable defense in depth, but they do not repair vulnerable code or replace HTTPS, access control, output encoding, dependency management, and monitoring. Strict policies should be built from observed requirements, not copied blindly.
Decision snapshot
| Decision | Practical approach | Watch for |
|---|---|---|
| Inventory before CSP | Map scripts, styles, fonts, images, frames, forms, connections, workers, and third-party origins. | A copied policy may break the site or allow far more than it needs. |
| Stage HSTS carefully | Confirm all hosts and subdomains intended for coverage support durable HTTPS before includeSubDomains or preload. | A long policy can make an overlooked HTTP-only service unreachable. |
| Use report mode as evidence | Collect and review violations before enforcing a restrictive policy. | Reports can be noisy and may include sensitive URL data, so handling needs controls. |
Establish the transport baseline
Redirect HTTP to HTTPS, use a valid maintained certificate, remove mixed content, review every subdomain, and confirm application and CDN behavior before HSTS changes.
Set straightforward protections
Apply X-Content-Type-Options: nosniff, an intentional Referrer-Policy, frame-ancestors through CSP or legacy frame control where needed, and a minimal Permissions-Policy based on used features.
Build Content Security Policy from assets
Inventory sources and inline behavior, replace unsafe inline code where practical with nonces or hashes, set restrictive defaults, control object, base, frame, form, and upgrade behavior, and avoid broad wildcards.
Observe, enforce, and refine
Start CSP in report-only on representative traffic, protect report collection, group actionable violations, test critical user and admin journeys, enforce gradually, and monitor after releases.
Verify every response path
Check HTML, redirects, errors, authenticated pages, downloads, APIs, CDN cache variants, subdomains, and third-party callbacks. Document ownership, exceptions, expiry, and rollback.
Action checklist
- HTTPS works without mixed content on every covered host
- HSTS scope, max-age, subdomains, preload implications, and rollback limits are reviewed
- Content types and referrer behavior match business needs
- Frame and browser-capability policies are explicit
- CSP sources are minimal and critical journeys pass without unsafe broad exceptions
- Headers are tested on redirects, errors, authenticated routes, and CDN responses
Working worksheet
Record these fields in the same working document so the decision can be reviewed and handed off:
- Host, route class, CDN or server layer, and owner
- Header, desired policy, threat addressed, and compatibility risk
- Required origin, directive, business reason, and removal plan
- Report-only result, false positive, remediation, and enforcement date
- Verification routes, monitoring, exception review, and rollback
Common failure patterns
- Adding unsafe-inline and broad wildcards until a copied CSP stops breaking the page
- Preloading HSTS before confirming every subdomain and long-term HTTPS ownership
- Setting headers in application code while CDN or server responses omit or overwrite them
Connect this work
Browser controls are only one layer. Read apply headers within a complete WordPress defense plan.
Security changes should preserve intended public content. Read check rendering and crawler access after policy changes.
Headers need ongoing operational maintenance. Read assign ownership and monitoring beyond the website.