Security headers · Check
CSP allows 'unsafe-inline' for script — switching to nonces or hashes
Your Content-Security-Policy includes `'unsafe-inline'` in `script-src` (or its `default-src` fallback) and does not provide a `nonce-` or `sha256-`/`sha384-` source. That tells the browser to execute every inline `<script>` block — including any an attacker manages to inject — which defeats the main reason to deploy CSP in the first place.
Why it matters
Generate a per-request nonce, attach it to your inline scripts (`<script nonce="...">`) and the matching `script-src 'nonce-...'` source, then drop `'unsafe-inline'`. Hashes work for static inline blocks. After that change, injected `<script>` tags are blocked by the browser without any application-side filtering.
Real-world risk
With 'unsafe-inline' in script-src, any injected <script> block (XSS) executes normally — the CSP is providing almost no protection against the bug class it's designed to mitigate.
Fix steps (in order)
- Generate a per-request nonce in your server response (a 128-bit random value, base64-encoded).
- Attach it to your inline scripts: <script nonce="...">...</script> and to script-src: script-src 'self' 'nonce-...';
- For static inline blocks, compute a SHA-256/384 hash and add 'sha256-...' / 'sha384-...' to script-src instead of nonces.
- Once nonces/hashes cover all legitimate inline scripts, remove 'unsafe-inline' from the policy.
Topic explainer
What is Content Security Policy (CSP)? A practical explainer →
An accessible explanation of Content Security Policy: what it does, why it exists, the directives that matter, and how to roll one out without breaking your app.
Verify the fix in 30 seconds
Run a Scorifya scan on the affected host after deploy. The same finding id (csp_unsafe_inline_script) clears once the externally-observable signal is in place.