CentralCSP

Main menu

All articles

Next Article

How to setup my reporting endpoint?

Stay safe, no more unsafe-inline

Tuesday, December 3, 2024

5 min read

Theotime Quere

Theotime Quere

'unsafe-inline' in Content Security Policy allows inline scripts and styles to execute, but it significantly weakens your security posture. Learn why you should avoid it and what alternatives to use instead.

What is unsafe-inline?

'unsafe-inline' is a CSP source directive value that allows inline scripts, styles, and event handlers to execute in your web application. While it might seem convenient, it essentially defeats much of the protection that CSP is designed to provide.

Example of CSP with unsafe-inline

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';

Why is unsafe-inline Dangerous?

  • XSS Vulnerability

    Allowing inline scripts means that if an attacker manages to inject malicious code into your HTML, it will execute without restriction.

  • Bypasses CSP Protection

    Using unsafe-inline negates many of the security benefits that CSP provides, as it allows any inline script to run regardless of its source.

  • Poor Security Practice

    It's considered a security anti-pattern and goes against modern web security best practices.

XSS Attack Example with unsafe-inline

Let's see how an attacker could exploit a website that uses unsafe-inline. Consider a simple blog with a comment system where user input isn't properly sanitized:

Vulnerable blog comment system


// Vulnerable: Comment is stored without sanitization on the server
app.post('/comment', (req, res) => {
  const comment = req.body.comment;
  saveComment(comment);
});

// Template rendering the comments 
<div class="comments">
  <!-- User comment inserted in the page and executed -->
  <script> -> Authorized as 'unsafe-inline' allow any inline script
    alert('Script injected!');
  </script>
</div>

This attack demonstrates several key points:

  • The server fails to sanitize user input, allowing HTML/JavaScript injection

  • The template renders content directly without escaping, creating an XSS vulnerability

  • With 'unsafe-inline' in the CSP, the injected script executes and can steal sensitive data

  • Without 'unsafe-inline', the browser would block the script execution, even with the XSS vulnerability present

Security Impact

Even if your application has XSS vulnerabilities, a properly configured CSP without unsafe-inline can prevent exploitation. This demonstrates why CSP acts as a crucial second layer of defense.

Common Uses of unsafe-inline

Developers often resort to unsafe-inline in these scenarios:

Inline event handlers in HTML

<button onclick="doSomething()">Click me</button>

Inline script tags

<script>
// This requires unsafe-inline
function doSomething() {
alert('Hello!');
}
</script>

Inline styles

<div style="color: red;">
This text uses inline styles
</div>

Better Alternatives

1. External Resources

Move all scripts and styles to external files:

External JavaScript file

// script.js
function doSomething() {
alert('Hello!');
}

// HTML
<script src="/js/script.js"></script>

2. Nonces

Use cryptographic nonces for cases where inline scripts are necessary:

CSP with nonce

Content-Security-Policy: script-src 'self' 'nonce-random123';

<script nonce="random123">
// Your inline script here
</script>
Learn more about implementing nonces with Next.js

3. Hashes

Use hashes to allow specific inline scripts:

CSP with hash

Content-Security-Policy: script-src 'self' 'sha256-hashOfYourScript';

<script>
// Only this exact script content will be allowed
console.log('Hello, world!');
</script>

Migration Strategy

  • Audit Current Usage

    Identify all instances of inline scripts and styles in your application.

  • Gradual Migration

    Move inline code to external files systematically, starting with the most critical sections.

  • Use Report-Only Mode

    Test your CSP without unsafe-inline using Content-Security-Policy-Report-Only header to identify violations.

  • Monitor Violations

    Set up a reporting endpoint to track CSP violations and identify missed inline scripts.

Common Pitfall

Don't use unsafe-inline as a quick fix for CSP violations. Instead, take the time to properly structure your code and use appropriate alternatives.

Best Practices

  • Never use unsafe-inline in production environments.

  • Always externalize JavaScript and CSS files.

  • Use nonces or hashes for unavoidable inline scripts.

  • Implement proper event handling through external JavaScript files.

  • Regular security audits to ensure no inline scripts are introduced.

Pro Tip

Use CSP reporting to catch any instances where inline scripts might be accidentally introduced during development.

Learn more about CSP reporting and monitoring

Conclusion

While unsafe-inline might seem like an easy solution to CSP-related issues, it significantly compromises your website's security. Instead, invest time in properly structuring your code and using secure alternatives like nonces, hashes, or external resources. Always maintain a robust reporting system to monitor and address CSP violations effectively.

Continue Reading

CSP & meta tags

Learn how to implement Content-Security-Policy using meta tags and understand the limitations compared to HTTP headers.

2024-11-16

4 min read

Theotime Quere

Theotime Quere

Read more →

Get started with CSP

Learn how to properly setup your CSP to ensure a secure configuration.

2024-12-03

5 min read

Theotime Quere

Theotime Quere

Read more →

Docs

CSP ScannerCSP EvaluatorReporting Endpoint

Contact


CentralSaaS © 2025