unsafe-inline in CSP

Last updated: April 2026

'unsafe-inline' in a CSP directive allows inline scripts or styles to execute. In script-src, it defeats the XSS protection that CSP is designed to provide.

What it allows

# With unsafe-inline in script-src, ALL of these execute:
<script>maliciousCode()</script>           # inline script tag
<button onclick="maliciousCode()">          # event handler
<a href="javascript:maliciousCode()">       # javascript: URL

Why it matters

If your site has an XSS vulnerability, an attacker can inject inline scripts. Without 'unsafe-inline', CSP blocks them. With it, CSP provides no protection against injected inline scripts.

Alternative 1 — nonces (recommended)

# CSP header — new nonce per request
Content-Security-Policy: script-src 'self' 'nonce-RANDOM_VALUE'

# Only scripts with the matching nonce execute
<script nonce="RANDOM_VALUE">legitimateCode()</script>

Alternative 2 — hashes

# Hash of the exact script content
Content-Security-Policy: script-src 'self' 'sha256-HASH'

# Calculate hash:
echo -n "legitimateCode()" | openssl dgst -sha256 -binary | base64

When unsafe-inline is less critical

In style-src, 'unsafe-inline' allows inline CSS. This is a lower risk than in script-src because CSS alone cannot exfiltrate data (in most cases). Many sites use it to support frameworks that inject inline styles.