An attacker's page can't read anything from another site — so how can a few lines of HTML still tell it whether you are logged in there?

By loading a resource that only exists for logged-in users and watching which event fires: onload means it was served, onerror means it wasn't. The answer comes from the load succeeding or failing, never from reading the content.

* The oracle — the attacker never reads the response, only observes which of the two handlers fired. *

The whole probe is one tag:

<img src="https://something.example.ch/src/images/icons/icon123.png"
     onload ='alert("User logged in")'
     onerror='alert("User not logged in")'/>

The browser fetches that image from the other site and attaches that site's cookies, exactly as it would for a legitimate embed. Then:

• the resource is served → the image decodes → onload fires
• the request is refused, redirected to a login page, or 404s → onerror fires

The same-origin policy did its job the whole time: the attacker's JavaScript never touched a single byte of the response. But it did not have to — which of the two handlers ran is itself one bit of information, and that bit is "this visitor has a session on that site". Pick a resource that only a logged-in user (or only a member of one group, or only the owner of one document) can fetch, and the same trick answers that question instead.

This is the classic first link of an attack chain. On its own, "is this person logged in?" is a privacy leak. Combined, it becomes targeting: XS-Leak confirms the victim has a live session, CSRF then fires a state-changing request into it, and XSS runs code in their context. Each step is more effective because the previous one removed the guesswork — and, conversely, breaking any single link stops the whole sequence.

Defences work by removing the observable difference, not by hiding the data: SameSite cookies so the probe request isn't authenticated in the first place, Cross-Origin-Resource-Policy / Fetch Metadata headers to refuse cross-site loads outright, and returning a uniform response whether or not the user is entitled to the resource.

Go deeper:

• XS-Leaks Wiki — error events — the onload/onerror oracle in detail, plus the headers that close it.