How to remove unsafe-inline?

csp-unsafe-inline-presentglobal

The unsafe-inline directive appears in Content Security Policy script-src and style-src declarations. It permits all inline scripts, event handlers, and inline styles to execute. CSP with unsafe-inline provides no protection against XSS attacks that inject inline code. The directive exists as a compatibility mechanism for sites with inline scripts. Removing unsafe-inline requires eliminating inline scripts and event handlers or implementing CSP nonces. Without unsafe-inline, CSP blocks inline code execution including XSS payloads.

What’s wrong

The Content Security Policy script-src or style-src directive includes the unsafe-inline keyword. This directive tells browsers to allow all inline scripts, inline event handlers, or inline styles depending on the context. CSP cannot distinguish between legitimate inline code and injected XSS payloads. The unsafe-inline directive permits both. XSS attacks inject malicious JavaScript through inline script tags or event handler attributes. CSP with unsafe-inline executes these payloads. The protection mechanism is disabled.

Why it matters

Content Security Policy without unsafe-inline prevents most XSS attacks. Attackers inject malicious code as inline scripts or event handlers. A strict CSP blocks these injections from executing. Adding unsafe-inline removes this protection. The policy becomes documentation rather than enforcement. Sites often add unsafe-inline as a quick fix when deploying CSP breaks functionality. This trades security for compatibility. The presence of unsafe-inline indicates the site has inline code that prevents strict CSP. Each inline script or handler is a potential injection point.

The correct change

Remove unsafe-inline from script-src and style-src directives. Identify all inline scripts and event handlers that break when unsafe-inline is removed. Move inline script code to external JavaScript files. Replace event handler attributes with addEventListener calls in external scripts. Implement CSP nonces if inline scripts cannot be externalized. Generate unique random nonces per response and add them to both the CSP header and script tags. The end state is CSP enforcement without unsafe-inline and all inline code either externalized or properly nonced.

Scope

This condition applies globally. The Content Security Policy header or meta tag affects the entire page. A single unsafe-inline directive permits all inline code regardless of source. Pages with no inline scripts still lack XSS protection if unsafe-inline is present. Some frameworks apply CSP at the application level affecting all responses. Others set CSP per response allowing gradual rollout. Global removal requires auditing all pages for inline code dependencies and addressing each systematically.

How to verify

• Validation confirms the condition is resolved:
• • CSP script-src directive does not contain unsafe-inline
• • CSP style-src directive does not contain unsafe-inline if relevant
• • All page functionality works without unsafe-inline
• • No inline scripts exist without valid CSP nonces
• • No inline event handlers exist on HTML elements
• • Browser console shows no CSP violations for blocked inline code
• • CSP enforces inline code restrictions as intended

Takeaway

• unsafe-inline disables Content Security Policy XSS protection completely
• CSP with unsafe-inline allows both legitimate inline code and XSS payloads
• Removing unsafe-inline requires eliminating inline scripts and event handlers
• CSP nonces provide an alternative when inline code cannot be externalized
• The presence of unsafe-inline indicates unresolved inline code dependencies

FAQ

Why is unsafe-inline considered worse than no CSP at all?

It creates false confidence. A CSP header with unsafe-inline appears to provide security but blocks only external script origins. XSS attacks primarily inject inline code not external scripts. Sites with unsafe-inline often believe they have XSS protection when they do not. No CSP is honest about the lack of protection. CSP with unsafe-inline is dishonest. Remove unsafe-inline or remove the CSP entirely until inline code is addressed.

Can unsafe-inline be used temporarily during CSP deployment?

Yes but with clear constraints. Deploy CSP in report-only mode with unsafe-inline to identify inline code locations. Fix inline scripts and handlers. Remove unsafe-inline from report-only CSP and monitor for violations. Once violations are resolved, enforce CSP without unsafe-inline. This phased approach maintains functionality while progressing toward strict CSP. Do not leave unsafe-inline in enforcing CSP indefinitely.

What if third-party scripts inject inline code?

Third-party scripts loaded from external URLs can inject inline code if unsafe-inline is present. Removing unsafe-inline blocks these injections. Some third-party integrations break. Contact vendors for CSP-compatible alternatives. Some provide nonce-compatible versions. Others require replacement. Weigh the security benefit of removing unsafe-inline against third-party functionality. Consider isolating third-party code to specific pages where unsafe-inline remains while protecting critical pages with strict CSP.

Does removing unsafe-inline break all sites initially?

Most sites break when unsafe-inline is removed without preparation. The degree depends on inline code prevalence. Modern JavaScript frameworks generate minimal inline code. Legacy applications and CMS platforms often rely heavily on inline scripts and handlers. Test in report-only mode first. The violations report shows what breaks. This allows planned remediation rather than sudden breakage. Expect significant effort for sites with substantial inline code.

How does unsafe-inline interact with nonces and hashes?

If nonces or hashes are present in script-src, browsers ignore unsafe-inline for script elements but still allow inline event handlers. This is called CSP Level 2 behavior. Inline scripts require nonces or hashes to execute. Event handlers still execute with unsafe-inline present. To block event handlers, remove unsafe-inline entirely. Complete protection requires no unsafe-inline and no inline event handlers.

What about unsafe-inline in style-src?

Inline styles have lower risk than inline scripts but still present security concerns. Inline CSS cannot execute JavaScript directly but can exfiltrate data through URLs in background-image and other properties. Removing unsafe-inline from style-src prevents these attacks. The same remediation patterns apply. Move styles to external CSS files or use CSP nonces for style tags. Prioritize removing unsafe-inline from script-src before addressing style-src.

The fix

Enable effective XSS protection by removing unsafe-inline from Content Security Policy

Done when: CSP enforces without unsafe-inline and all inline code is externalized or properly nonced

Do not

• Do not use unsafe-inline as a permanent CSP configuration
• Do not believe CSP with unsafe-inline provides XSS protection
• Do not add unsafe-inline to fix CSP violations without addressing root cause
• Do not ignore inline event handlers when removing unsafe-inline

How to verify

• CSP script-src contains no unsafe-inline directive
• CSP style-src contains no unsafe-inline directive if present
• All inline code externalized or nonced
• Page functionality unchanged
• Console shows no violations for blocked inline code

Find every page with this

probeo monitors this continuously across every page of your site, and records which pages passed, which failed, and which it could not determine.