Content Security Policy (CSP) Bypass Vulnerabilities

Content-Security-Policy: 
  default-src 'none';
  script-src 'self';
  connect-src 'self';
  img-src 'self';
  style-src 'self';
  font-src 'self';
  base-uri 'self';
  form-action 'self';
  frame-ancestors 'none';
  object-src 'none'
        

// Server-side code generates a random nonce for each response
const nonce = crypto.randomBytes(16).toString('base64');

// Add the nonce to your CSP header
response.setHeader('Content-Security-Policy', `script-src 'self' 'nonce-${nonce}'`);

// In your HTML, add the nonce to each script tag
<script nonce="<%= nonce %>">
  // This inline script will be allowed by CSP
  console.log('Hello, secure world!');
</script>
        

<script 
  src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js" 
  integrity="sha384-vtXRMe3mGCbOeY7l30aIg8H9p3GdeSe4IFlP6G8JMa7o7lXvnz3GFKzPxzJdPfGK" 
  crossorigin="anonymous">
</script>
        

Content-Security-Policy: ...; require-sri-for script style
        

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-violation-report
        

Content-Security-Policy: script-src 'nonce-{random}' 'strict-dynamic'; object-src 'none'; base-uri 'none'
        

With 'data:' URIs allowed in script-src, attackers can inject base64-encoded JavaScript.

For example: <script src="data:text/javascript;base64,YWxlcnQoJ1hTUyBBdHRhY2shJyk="></script> would execute.

Missing critical directives means the browser falls back to default behaviors, which may be insecure.

For example, without object-src defined, Flash objects could be embedded and exploited.

With wildcard domains allowed, attackers can host malicious JavaScript on any HTTPS site.

This is equivalent to having no CSP for script sources.

JSONP endpoints can be abused to execute arbitrary JavaScript if included in your whitelist.

For example: <script src="https://ajax.googleapis.com/ajax/services/feed/find?v=1.0&q=xss&callback=alert"></script>

AngularJS template injection can bypass CSP restrictions because AngularJS evaluates expressions within curly braces, which doesn't count as JavaScript execution from CSP's perspective. If AngularJS is loaded from a whitelisted domain, this can be exploited.

JSONP endpoints can be abused if they're on domains in your whitelist. These endpoints wrap JSON data in a callback function, and if this callback parameter isn't properly validated, it can be used to execute arbitrary JavaScript.

DOM-based XSS can bypass CSP if the page uses dangerous functions like eval() or document.write() with user input. This example exploits a page that allows 'unsafe-eval' by manipulating the DOM through allowed JavaScript.

If your CSP allows iframes (frame-src) but doesn't properly restrict them, attackers can use the srcdoc attribute to inject HTML and JavaScript. The content of srcdoc is governed by the parent page's origin, not by CSP's frame-src directive.

Script gadgets are legitimate JavaScript functions that can be repurposed for attacks. This example uses Knockout.js's data binding to execute HTML that contains a script tag. Even though the CSP blocks inline scripts, the framework processes the HTML and executes the code.

If object-src isn't set to 'none', attackers can use <object> tags with data URIs to execute JavaScript. The example uses a base64-encoded HTML document with a script that would execute in browsers that support this bypass.

In a real environment with AngularJS loaded, this payload would execute JavaScript through Angular's template engine. The CSP wouldn't block it because the code execution happens through Angular's legitimate JavaScript rather than through a script tag or event handler.

In a real environment, this would load a JSONP endpoint with 'alert' as the callback function. When the response arrives, it would execute alert('data') instead of the expected callback function.

This attack uses a javascript: URL with encoded content to bypass CSP. If the page uses this value in an unsafe way (like in eval() or innerHTML), the payload would execute despite CSP restrictions.

The srcdoc attribute creates a new document within the iframe that inherits the parent page's origin. This means scripts within it execute in the context of your domain, bypassing CSP frame-src restrictions.

If the page uses a framework like Knockout.js, this payload would cause the framework to process the HTML string and execute the script. The CSP doesn't block this because the script execution happens through the legitimate framework code.

This creates an object element with a data URI containing HTML and JavaScript. If object-src isn't restricted to 'none', this could execute in supported browsers, bypassing script-src restrictions.

CSP Bypass Demonstration

Payload: ${payload}

Note: For security reasons, this demo doesn't actually execute the bypass, but shows how it would work in a vulnerable environment.

This basic CSP configuration provides good protection against common attacks:

• Restricts scripts to the same origin
• Blocks object embeds completely
• Prevents base tag hijacking
• Stops clickjacking by restricting framing
• Limits form submissions to the same origin

This strict policy uses a "deny by default" approach, explicitly defining all allowed resource types:

• Sets default-src to 'none', requiring explicit allowance for each resource type
• Blocks all framing with frame-ancestors 'none' (stronger protection than X-Frame-Options)
• Prevents base URI manipulation with base-uri 'none'
• Uses Trusted Types to prevent DOM XSS attacks in modern browsers

This nonce-based policy allows specific inline scripts without 'unsafe-inline':

• Uses a random nonce (${nonce}) that must be included in script tags
• Example: <script nonce="${nonce}">alert('This is allowed');</script>
• Attackers can't guess the nonce, so injected scripts won't execute
• The nonce must be regenerated for each page load

This hash-based policy allows specific inline scripts by their hash:

• The hash 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=' corresponds to console.log('Hello, secure world!');
• Only scripts with matching hashes will execute
• Any change to the script content, even a single character, will change the hash and block execution
• Good for static scripts that don't change often

Report-Only mode lets you test a CSP without enforcing it:

• Browsers will report violations but still allow blocked resources to load
• Sends violation reports to the specified endpoint
• Useful for testing a new policy before deployment
• Helps identify legitimate resources that would be blocked

With 'unsafe-inline' allowed, XSS attacks through inline scripts can succeed.

Check the iframe above to see if the script executed. In a real browser with this CSP, an alert would appear.

With 'unsafe-eval' allowed, attackers can use eval() and similar functions if they control input to those functions.

This is particularly dangerous in applications that parse and execute JSON or other user-controlled data.