How to Fix CSP Unsafe Inline
Use this page when the CSP Checker shows unsafe-inline or similar execution patterns that weaken script restrictions.
What This Means
Leaving unsafe-inline in production often means the site is relying on legacy script patterns or vendor snippets that were never refactored. A safer remediation path is to identify what still needs inline execution, move low-risk code out first, and then replace the remaining cases with nonces or hashes.
| Directive | What to verify | Why it matters |
|---|---|---|
| script-src | Whether unsafe-inline or unsafe-eval is still present | These are the highest-value CSP cleanup targets. |
| Inline bootstrap code | Theme, framework, or tag-manager snippets | These are common blockers to policy tightening. |
| Third-party hosts | Whether the allowlist is broader than needed | Overly broad hosts reduce the value of stricter CSP. |
| Report-only telemetry | Whether violations are being collected | Safer rollout depends on real evidence, not guesses. |
Common Causes
Patterns worth checking first
- Legacy templates: Inline scripts were never moved into external assets or nonce-backed execution.
- Vendor snippets: Tag managers and embedded integrations encouraged quick inline setup.
- Fear of regressions: Teams kept unsafe-inline because there was no report-only rollout process.
How To Confirm It Safely
Confirmation steps
- Capture the live CSP header exactly as browsers receive it.
- Identify which pages still rely on inline execution and why.
- Use report-only data or console evidence before tightening enforcement.
- Separate necessary third-party scripts from stale or redundant ones.
Fix Workflow
- Inventory inline behavior. Find which templates, widgets, or tags still require inline execution.
- Refactor easy wins first. Move simple inline code into external files or safer patterns before tackling hard cases.
- Use nonces or hashes where needed. Apply the narrowest practical replacement for the remaining inline behavior.
- Promote enforcement with evidence. Retest high-value user journeys and confirm the stricter policy still works.
Implementation Examples
Nonce-based script example
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-random123'; object-src 'none'; base-uri 'self';Rollout Risks
Removing unsafe-inline too early can break tag-manager or bootstrap logic
Some apps still depend on inline startup code even when teams think they do not.
- Use report-only or browser console evidence first.
- Retest critical templates after every policy change.
A nonce rollout still fails if the response path is inconsistent
Caches, CDNs, or partial template rendering can break nonce handling if not designed carefully.
- Confirm every rendered script receives the right nonce.
- Review edge caching if CSP differs by request context.
Validation Checklist
Post-fix validation
- unsafe-inline is removed or deliberately limited based on actual need.
- The final policy works on critical templates and flows.
- Violation telemetry no longer shows the original high-priority inline issues.
- The CSP Checker confirms the safer directive posture.
FAQ
Should I use hashes or nonces?
It depends on how stable the inline content is.
- Use hashes for static inline blocks.
- Use nonces when content varies per response.
Can I keep unsafe-inline temporarily?
Yes, if it is part of a staged remediation plan rather than the permanent end state.
- Set a concrete refactor target.
- Do not leave it in place without report-driven cleanup.