Cybersecurity glossary
What is a Cross-Origin Information Leak?
Learn what a cross-origin information leak is, how browsers can reveal cross-site state through side channels, how XS-Leaks relate, and which isolation headers reduce exposure.
Definition
A cross-origin information leak is any unintended disclosure of data about one origin’s content or user state to a different origin—often through side channels such as timing, error behavior, frame load outcomes, or other browser APIs—rather than through a direct same-origin read.
Why cross-origin information leaks matter
The same-origin policy blocks evil.example from reading bank.example’s DOM. Attackers still ask: “Can I learn anything useful anyway?” A cross-origin information leak answers yes—through timing, framing success/failure, cache behavior, or other side channels.
Even a single bit—“is this user logged in?”—can drive phishing, account linking, or secondary exploits.
How these leaks arise
Pick a cross-origin oracle
Choose a browser behavior that differs based on victim-site state.
Trigger from the attacker page
Load, frame, fetch, or navigate to a victim URL under the user’s session.
Measure the side channel
Observe timing, errors, window handles, resource size hints, or load events.
Infer private state
Map measurements back to login status, content existence, or other secrets.
Act on the insight
Personalize attacks or chain into further exploitation.
Example leak categories
Frameability oracles
Whether a page allows embedding can reveal path or auth differences.
Timing oracles
Authenticated vs anonymous responses take different amounts of time.
Error oracles
Distinct status codes or redirect chains expose object existence.
Window / opener oracles
Relationships between windows leak navigations and cross-site state.
Mitigation building blocks
| Control | Helps reduce |
|---|---|
| COOP | Cross-window attacks and some opener-based leaks |
| COEP + isolation | Powerful cross-origin embed interactions |
| frame-ancestors / XFO | Unwanted framing oracles and clickjacking |
| Uniform errors | Existence leaks via distinct 404/403/redirect behavior |
| Fetch Metadata | Unexpected cross-site resource loads |
| SameSite cookies | Credentialed cross-site probing usefulness |
Design checklist
- Assume attackers can probe your URLs cross-site and observe side effects.
- Avoid auth-dependent differences in framing, redirects, and error pages when possible.
- Deploy COOP on sensitive application origins.
- Use CSP frame-ancestors to control embedding deliberately.
- Review XS-Leaks patterns against login and multi-tenant object URLs.
- Prefer same-site architecture for highly sensitive user state.
- Test with third-party cookies blocked and with them allowed.
- Treat ‘one-bit leaks’ as real privacy and security bugs.
The practical takeaway
A cross-origin information leak discloses another origin’s private state without a direct DOM read—usually via side channels. Same-origin policy is necessary but not sufficient against clever oracles.
Design responses to look alike across states where feasible, adopt isolation headers, and review your app through an XS-Leaks lens—not only a classic XSS/CSRF checklist.
Related security terms
XS-Leaks
A catalog of cross-site leak techniques that realize cross-origin information leaks.
Cross-Origin Opener Policy (COOP)
Isolation header that reduces window-based cross-origin interactions.
Cross-Origin Embedder Policy (COEP)
Embedder policy used with isolation to constrain cross-origin loads.
Same-Origin Policy (SOP)
Primary confidentiality boundary that side channels attempt to undermine.
Frequently asked questions
What is a cross-origin information leak?
It is when site A learns something private about site B or the user’s state on site B without being allowed to read site B’s content directly.
How is this different from XSS?
XSS runs code inside the victim origin. Cross-origin leaks usually keep the attacker on their own origin and infer secrets through side channels.
What kinds of secrets leak?
Login state, the existence of content, approximate sizes, redirect targets, permission states, and other yes/no or low-bit facts that still matter.
Are these bugs in my application or the browser?
Often both: browser APIs expose signals, and application designs (distinct error URLs, embeddable private content) make those signals meaningful.
What helps mitigate leaks?
COOP/COEP isolation, Fetch Metadata protections, careful framing controls, uniform error handling, SameSite cookies, and avoiding state-dependent cross-origin resource behavior.
Is CORS a complete fix?
No. CORS governs many explicit reads, but timing and other side channels can still disclose information.
Why should product teams care about one-bit leaks?
One bit can mean ‘user is logged in’ or ‘this email exists,’ which enables targeted attacks and privacy violations.
References
Explore authoritative guidance and frameworks related to cross-origin information leak.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.