The top 30 CSP bypass techniques known in the CTF and bug bounty hunting communities, along with their explanations and use cases:
1-10: Inline Script and Style Bypasses
- Nonce Reuse: If a
nonce
is reused across multiple responses or can be guessed, attackers can inject content with the known nonce. - Dynamic Script Injection via
strict-dynamic
: Usingscript-src 'strict-dynamic'
allows dynamically created scripts (e.g., usingeval()
) which can lead to bypass if combined with a trusted script. - Whitelisted JSONP Endpoints: Exploiting
script-src
that allows external JSONP endpoints to execute arbitrary JavaScript. - Data URI Whitelisting: Using
data:
URIs inscript-src
orstyle-src
may allow execution of inline scripts if enabled. - Blob URI Whitelisting: If
blob:
is allowed, attackers can create blob URLs containing malicious content. - Self Whitelisting with User-Controlled Content: When
script-src 'self'
is used and the site reflects user input without sanitization. - Inline Event Handlers with
'unsafe-inline'
: Allows using event handlers directly in HTML (onclick
, etc.), exploitable in lenient CSPs. - Bypass via
innerHTML
: Using DOM manipulation functions that insert unsanitized HTML (e.g.,innerHTML
,document.write
). - Base Tag Injection: Injecting
<base>
tags to manipulate relative paths ifdefault-src
is too permissive. - Bypass using
unsafe-eval
: CSP that allowsunsafe-eval
permits functions likeeval()
,setTimeout()
, andsetInterval()
.
11-20: Source and Fetch Policy Bypasses
- Permissive Wildcard for Script Sources: Using
script-src *
allows loading scripts from any domain. - Third-party Libraries with XSS Vulnerabilities: Libraries allowed by CSP may have vulnerabilities that allow script injection.
- Compromised CDN Whitelist: Whitelisted CDNs that host user-controlled content.
- Content-Type Mismatch: Allowing non-JS content (e.g., images) to be served with
application/javascript
MIME type. - MIME Sniffing Bypass: Improper MIME-type checks may allow arbitrary script injection.
- URL Parameter Injection: Fetching scripts using user-controllable parameters (e.g.,
example.com/script.js?payload=...
). - Redirection to Malicious Domains: If a whitelisted domain redirects to a malicious site.
- JSON Hijacking via
img-src
orconnect-src
: If CSP allows loading JSON or data from external sources. - Subresource Integrity (SRI) Misconfiguration: Incorrect or missing integrity attributes for scripts.
- Allowing
filesystem:
URIs: Can lead to arbitrary file reads and writes in some contexts.
21-30: Policy and Reporting Mechanism Bypasses
- Policy Parsing Errors: Exploiting browser-specific quirks or bugs in CSP parsing logic.
- Case-sensitivity Bypass: Using case-insensitive variations of directives in some browsers (
sCrIpT-sRc
). - Misconfigured Frame Ancestors: Weak
frame-ancestors
allowing clickjacking. - Policy Injection via Meta Tags: Injecting new CSP directives through
<meta http-equiv="Content-Security-Policy">
. - Weak Default-src with Fallback: Using lenient
default-src
when specific directives are missing. - Cross-origin Redirection Chains: Using chained redirects to bypass origin restrictions.
- Bypassing Wildcards in Subdomains: Exploiting
*.example.com
when sensitive subdomains should be excluded. - Improper Nonce Scope Management: Using nonces outside of intended scope (e.g., on subresources).
- Report URI Manipulation: Poisoning reports sent to
report-uri
for information leakage. - Abusing CSP Report-only Mode: CSP in
report-only
does not block execution, only reports violations.
Summary
CSP bypasses are possible due to misconfigurations, overly permissive policies, browser quirks, and untrusted third-party resources. Properly auditing and refining CSP configurations while following best practices helps mitigate these risks. Always test CSP headers using tools like csp-evaluator
and browser developer tools to identify potential weaknesses.