Full Report
Self-XSS is when you can trigger cross site scripting (XSS) but only on yourself. This post goes into a few ways to make self-XSS exploitable, with the final one being the most interesting. The main topic of discussion is credentialless iframes. A credentialness iframe is an iframe that is loaded inside of a different context than those on the same origin. Since iframes on the same origin is able to edit other frames on other origins, it's able to edit the logged in iFrame still. If the page contains login CSRF then the usage of credentialless iframes becomes useful. Create a login CSRF attack on a victim and get the victim to visit the website. On the same page with the login CSRF to a page that contains two iFrames: one with the credentialless iFrame and another with the regular user login. Use the XSS on the credentialless iFrame to write into the context of the other iFrame. This leads to many security issues. The second idea is using clickjacking to trick a user to login to an account instead. This works when CSRF login is not possible. Both of the previous techniques require iframes to be allowed on a page though. The coolest example is the final one, by far. In 2025 the function fetchLater function was added. This will send requests after some time, even if the tab is closed. This means it may be possible to do the following: Trigger self-XSS on an account you control. Call fetchLater for a fetch requests that uses cookies for a sensitive API. Logout of the account. User logs into the account later. The fetchLater request runs in the context of the users session. This is an easy account takeover from here! On the Critical Thinking podcast, the host Justin claims that the closing at Chrome will shoot off all the requests, making it not good for . To get around this, an attacker can stall the HTTP response on a server that they control with maximum length timeouts in Chrome and redirects. Eventually, the redirect can go to a malicious endpoint on the regular server from the context of the Chrome request. I think that the redirect will lead to a resubmission of the cookies, such as the new cookies of the logged in user. Pretty neat!
Analysis Summary
# Vulnerability: Self-XSS Escalation via Credentialless Iframes and fetchLater
## CVE Details
- **CVE ID**: N/A (Exploitation of web platform features and logic flaws)
- **CVSS Score**: Estimated 7.5 to 8.3 (High)
- **CWE**: CWE-79 (Cross-site Scripting), CWE-352 (Cross-Site Request Forgery), CWE-1385 (Missing Origin Isolation in Credentialless Iframes)
## Affected Systems
- **Products**: Modern Web Browsers (specifically Chromium-based browsers supporting `credentialless` iframes and the `fetchLater` API).
- **Versions**: Chrome 110+ (for credentialless iframes), Chrome 121+ (for `fetchLater` experimental support/2025 implementations).
- **Configurations**: Web applications containing Stored Self-XSS and lacking robust CSRF protections on login endpoints or lacking strict Frame Options (CSP `frame-ancestors` or `X-Frame-Options`).
## Vulnerability Description
This summary details techniques to escalate "Self-XSS" (traditionally considered low-impact) into full Account Takeover (ATO).
1. **Credentialless Iframe Escape**: Because `credentialless` iframes are same-origin with regular iframes (but use ephemeral storage), an attacker can load their own account (containing Self-XSS) in a credentialless frame alongside a victim's session in a standard frame. The XSS in the attacker's context can access and script the victim's context due to the shared origin.
2. **fetchLater Deferred Execution**: The `fetchLater()` API allows requests to be queued and sent even after a page is closed. By combining this with server-side delays and redirects, an attacker can trigger a payload in their own session that "waits" until the victim logs into their own account, at which point the queued request fires using the victim's new session cookies.
## Exploitation
- **Status**: PoC available (Conceptual and technical demonstration provided).
- **Complexity**: Medium
- **Attack Vector**: Network (Web-based)
## Impact
- **Confidentiality**: High (Access to victim cookies, private data, and session tokens).
- **Integrity**: High (Ability to perform actions on behalf of the victim via scripted sessions).
- **Availability**: Low (Primary impact is unauthorized access).
## Remediation
### Patches
- This is an architectural issue involving browser features; no specific "patch" exists for the APIs themselves. Developers must secure applications against the underlying primitives.
### Workarounds
- **Strict Transport Security & Cookie Flags**: Use `SameSite=Strict` for session cookies to prevent them from being sent in cross-site iframe contexts.
- **Frame Defense**: Implement `Content-Security-Policy: frame-ancestors 'none';` or `X-Frame-Options: DENY` to prevent the application from being embedded in the malicious iframes required for the attack.
- **Login CSRF Protection**: Ensure all login forms utilize anti-CSRF tokens or mandatory user interaction (like non-predictable CAPTCHA validation tied to the session).
## Detection
- **Indicators of Compromise**:
- Unexpected POST requests to sensitive endpoints (e.g., `/change_rights`, `/update_email`) occurring shortly after a user logs in.
- Presence of `credentialless` attributes in third-party iframes on suspicious sites.
- **Tools**: Browser developer tools (Network tab) can identify queued `fetchLater` requests. Modern WAFs can be configured to block unexpected cross-origin login attempts.
## References
- MDN - Credentialless iframes: [https://developer.mozilla.org/en-US/docs/Web/Security/IFrame_credentialless](https://developer.mozilla.org/en-US/docs/Web/Security/IFrame_credentialless)
- WICG - Anonymous Iframe Explainer: [https://wicg.github.io/anonymous-iframe/](https://wicg.github.io/anonymous-iframe/)
- Slonser Notes: [https://blog.slonser.info/posts/make-self-xss-great-again/](https://blog.slonser.info/posts/make-self-xss-great-again/)