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
Read more →
Main menu
All articles
Next Article
How to setup my reporting endpoint?
'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.
'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';
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.
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.
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>
Move all scripts and styles to external files:
External JavaScript file
// script.js
function doSomething() {
alert('Hello!');
}
// HTML
<script src="/js/script.js"></script>
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>
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>
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.
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.
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.
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
Read more →
Learn how to properly setup your CSP to ensure a secure configuration.
2024-12-03
5 min read
Theotime Quere
Read more →
Main menu
All articles
Written by
Theotime Quere
CentralSaaS © 2025