Security Safety Net Weakened by Permissive Script Settings

Vulnerability Explanation

The Content-Security-Policy header is present but includes both 'unsafe-inline' and 'unsafe-eval' in its script-src (or default-src) directive. 'unsafe-inline' permits execution of all inline <script> blocks, inline event handlers (onclick, etc.), and javascript: URIs. 'unsafe-eval' permits string-to-code execution via eval(), Function(), setTimeout(string), and similar APIs. Together, these two directives eliminate the two most impactful protections CSP provides against cross-site scripting: blocking injected inline scripts and blocking dynamic code evaluation. An attacker who finds any XSS injection point can exploit it freely, as the browser will not block the injected code.

Root Cause

These directives are typically added because the application relies on inline scripts (e.g., legacy jQuery event handlers, server-rendered script blocks, third-party tag managers) or libraries that use eval() internally. Rather than refactoring the code or using nonces/hashes, developers take the shortcut of permitting all inline execution globally.

Technical Impact

If an XSS vulnerability exists anywhere in the application, the weakened CSP provides no additional barrier. An attacker can execute arbitrary JavaScript in a victim's browser context: stealing session cookies or tokens, performing actions on behalf of the user, exfiltrating sensitive data visible on the page, or redirecting users to phishing pages. The CSP header exists but provides negligible XSS protection in its current state.

Severity Justification

This is a defence-in-depth control failure, not a standalone exploitable vulnerability. Exploitability depends entirely on the presence of a separate XSS flaw. CVSS is moderate because the weakened CSP amplifies the impact of other vulnerabilities rather than being directly exploitable on its own.

Affected Components

• Content-Security-Policy header — all versions using 'unsafe-inline' or 'unsafe-eval' in script-src or default-src

Remediation Steps

1. Start in report-only mode: rename the header to Content-Security-Policy-Report-Only and add a report-uri or report-to endpoint. This lets you observe what would be blocked without breaking anything.
2. Audit your codebase for inline scripts, inline event handlers (onclick=, onload=, etc.), javascript: URLs, and eval() / Function() / setTimeout(string) calls. Move inline scripts to external .js files where possible.
3. Replace 'unsafe-inline' with a per-request nonce for server-rendered pages: generate a cryptographically random nonce on each response, add it to the CSP header as 'nonce-{RANDOM}', and add the matching nonce attribute to every legitimate <script> tag. For static/SPA sites, use SHA-256 hashes instead.
4. Replace 'unsafe-eval' by refactoring eval() usages. For third-party libraries that require eval (e.g., some older bundlers or template engines), consider upgrading to eval-free versions or using the Trusted Types API as a safer alternative.
5. Add 'strict-dynamic' alongside your nonce or hash to allow trusted scripts to load dynamic child scripts without re-listing every source.
6. Once report-only monitoring shows no unexpected violations, promote the header to enforcing mode: Content-Security-Policy.

Verification Steps

1. Run: curl -I https://your-site.com and confirm the Content-Security-Policy response header no longer contains 'unsafe-inline' or 'unsafe-eval'.
2. Open Chrome DevTools → Console and load your application. Look for any CSP violation errors (red messages starting with 'Refused to execute'). Fix each violation before enforcing.
3. Paste your final policy into Google's CSP Evaluator at https://csp-evaluator.withgoogle.com/ and confirm it passes without high-severity warnings.
4. Run Lighthouse (v7.3.0+) with --preset=experimental and check the Best Practices audit for CSP strength.

Code Examples (nginx)

# Nginx — current weak policy
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval';";

# Express/Node — current weak policy
app.use((req, res, next) => {
  res.setHeader('Content-Security-Policy', "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'");
  next();
});

# Nginx — nonce-based strict policy (nonce injected by app layer)
add_header Content-Security-Policy "script-src 'nonce-$request_id' 'strict-dynamic'; object-src 'none'; base-uri 'none';";

# Express/Node — nonce-based strict policy
import { randomBytes } from 'crypto';

app.use((req, res, next) => {
  const nonce = randomBytes(16).toString('base64');
  res.locals.cspNonce = nonce;
  res.setHeader(
    'Content-Security-Policy',
    `script-src 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'none';`
  );
  next();
});

// In your HTML template, add the nonce to every <script> tag:
// <script nonce="<%= cspNonce %>">...</script>

# Hash-based alternative for static/SPA sites
# Content-Security-Policy: script-src 'sha256-{BASE64_HASH_OF_SCRIPT}' 'strict-dynamic'; object-src 'none'; base-uri 'none';

Best Practices

• Never use 'unsafe-inline' or 'unsafe-eval' as a permanent fix — use nonces or hashes to allow specific trusted scripts instead.
• Generate a fresh cryptographic nonce for every HTTP response; a static or predictable nonce provides no protection.
• Keep CSP in report-only mode during rollout and monitor violation reports before switching to enforcement.
• Treat CSP as a second layer of defence — it does not replace proper input validation and output encoding in your application code.

References

• cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
• web.dev/articles/strict-csp
• developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
• csp-evaluator.withgoogle.com/
• csp.withgoogle.com/docs/strict-csp.html