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

  1. Nonce Reuse: If a nonce is reused across multiple responses or can be guessed, attackers can inject content with the known nonce.
  2. Dynamic Script Injection via strict-dynamic: Using script-src 'strict-dynamic' allows dynamically created scripts (e.g., using eval()) which can lead to bypass if combined with a trusted script.
  3. Whitelisted JSONP Endpoints: Exploiting script-src that allows external JSONP endpoints to execute arbitrary JavaScript.
  4. Data URI Whitelisting: Using data: URIs in script-src or style-src may allow execution of inline scripts if enabled.
  5. Blob URI Whitelisting: If blob: is allowed, attackers can create blob URLs containing malicious content.
  6. Self Whitelisting with User-Controlled Content: When script-src 'self' is used and the site reflects user input without sanitization.
  7. Inline Event Handlers with 'unsafe-inline': Allows using event handlers directly in HTML (onclick, etc.), exploitable in lenient CSPs.
  8. Bypass via innerHTML: Using DOM manipulation functions that insert unsanitized HTML (e.g., innerHTML, document.write).
  9. Base Tag Injection: Injecting <base> tags to manipulate relative paths if default-src is too permissive.
  10. Bypass using unsafe-eval: CSP that allows unsafe-eval permits functions like eval(), setTimeout(), and setInterval().

11-20: Source and Fetch Policy Bypasses

  1. Permissive Wildcard for Script Sources: Using script-src * allows loading scripts from any domain.
  2. Third-party Libraries with XSS Vulnerabilities: Libraries allowed by CSP may have vulnerabilities that allow script injection.
  3. Compromised CDN Whitelist: Whitelisted CDNs that host user-controlled content.
  4. Content-Type Mismatch: Allowing non-JS content (e.g., images) to be served with application/javascript MIME type.
  5. MIME Sniffing Bypass: Improper MIME-type checks may allow arbitrary script injection.
  6. URL Parameter Injection: Fetching scripts using user-controllable parameters (e.g., example.com/script.js?payload=...).
  7. Redirection to Malicious Domains: If a whitelisted domain redirects to a malicious site.
  8. JSON Hijacking via img-src or connect-src: If CSP allows loading JSON or data from external sources.
  9. Subresource Integrity (SRI) Misconfiguration: Incorrect or missing integrity attributes for scripts.
  10. Allowing filesystem: URIs: Can lead to arbitrary file reads and writes in some contexts.

21-30: Policy and Reporting Mechanism Bypasses

  1. Policy Parsing Errors: Exploiting browser-specific quirks or bugs in CSP parsing logic.
  2. Case-sensitivity Bypass: Using case-insensitive variations of directives in some browsers (sCrIpT-sRc).
  3. Misconfigured Frame Ancestors: Weak frame-ancestors allowing clickjacking.
  4. Policy Injection via Meta Tags: Injecting new CSP directives through <meta http-equiv="Content-Security-Policy">.
  5. Weak Default-src with Fallback: Using lenient default-src when specific directives are missing.
  6. Cross-origin Redirection Chains: Using chained redirects to bypass origin restrictions.
  7. Bypassing Wildcards in Subdomains: Exploiting *.example.com when sensitive subdomains should be excluded.
  8. Improper Nonce Scope Management: Using nonces outside of intended scope (e.g., on subresources).
  9. Report URI Manipulation: Poisoning reports sent to report-uri for information leakage.
  10. 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.