Home / Knowledge hub / Cross-site leaks
Knowledge hub
Cross-site leaks
Small side effects, like timing or errors, that let another site infer private data.
What it means
Cross-site leaks, also called XS-Leaks, are a family of browser tricks. A malicious page makes the visitor's browser send requests to another site, then watches small side effects: how long a response takes, how many frames it creates, whether an error fires, or whether a file was cached.
The page cannot read the other site's content directly, because the same-origin policy blocks that. It learns a yes-or-no answer about it instead, and repeated answers can add up to something private.
Why it matters
The leaked fact can be sensitive even though no page content is copied. Whether a search returns results, whether an email address belongs to an account, or whether someone is a member of a group can all be inferred, and from that, who a person is or what they have done.
Because nothing is stolen in the usual sense, the logs look normal. These issues are often dismissed as theoretical, so teams hold back, yet they can turn private pages into a small oracle for anyone who can get a visitor to open a link.
How it shows up
The pattern needs a page that answers differently depending on who is signed in or what they own, and a browser that sends the visitor's cookies with a cross-site request. Search results, download endpoints and redirects are typical candidates.
The mistakes repeat. Cookies are sent on every cross-site request. Responses differ in size, timing or redirect target depending on the data. Pages can be framed by anyone. Look at SameSite cookies, the Cross-Origin-Opener-Policy header and Fetch Metadata request headers.
Questions people ask
Cross-site leaks, answered
Is a cross-site leak the same as XSS?
No. XSS runs the attacker's script inside your page. A cross-site leak runs on the attacker's own site and only watches side effects, so the attacker never gets to run code on yours.
The fixes differ too.
Is it the same as CSRF?
Related, but different. CSRF makes a browser change something on your site. A cross-site leak makes the browser ask a question and learns from the side effects of the answer.
Both depend on cookies being sent with cross-site requests.
How do we reduce the risk?
Set cookies to SameSite Lax or Strict where you can, use Cross-Origin-Opener-Policy, and check Sec-Fetch-Site on sensitive endpoints to refuse cross-site requests. Make responses similar in shape and timing.
Block framing with CSP frame-ancestors for pages that do not need it.
Can a scanner find these?
Seldom. They depend on behaviour that differs by account and data, so a tool that sends the same request to everything may see nothing wrong.
They are found by someone comparing how a page behaves for different signed-in accounts and from another origin.
Do browsers fix this for us?
Partly. Browsers have moved towards SameSite=Lax by default and have added isolation features, which closes some routes. Others stay open.
You still need your own headers and checks on endpoints that expose private data.
Sources
Where this comes from
Related
Terms that sit next to this one
Same-origin policy
The browser rule that stops one site's scripts reading another site's data.
SameSite cookie
A cookie setting that limits when a browser sends it on requests from other sites.
Cross-Origin-Opener-Policy
A header that isolates your page from windows opened by other sites.
CSRF
An attacker's page makes a logged-in user's browser act on your site.
Clickjacking
Tricking someone into clicking your button while it is hidden from them.
What does your page give away?
Pages that answer differently for different signed-in accounts are where we look, including cross-account access. Each finding comes with the request and response that prove it. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.