Cross-site login detection uses timing, error events, and redirects to infer which services you're signed into — how it works and how browsers now block it.
Key Takeaways
- Login status is a side channel. The Same-Origin Policy stops a site from reading your cookies or session data on another origin, but it never promised to hide whether a resource behaved differently because you were logged in somewhere else.
- Resource and timing probes exploit caching and load duration: a URL that only loads fast (or loads at all) for a logged-in session leaks a single bit of information every time it's requested from an attacker's page.
- Redirect- and error-based detection watches
onload/onerrorevents or CSP violation reports fired by a hidden<img>,<script>, or<link>pointed at an authenticated endpoint — logged-in and logged-out sessions produce different, observable outcomes. - What it reveals: correlating this signal across dozens of sites builds a profile of which bank, health portal, forum, or dating app you use — without ever learning your name — which is exactly what makes it useful for targeted phishing.
- Cookie blocking, storage partitioning, and cache partitioning close most of it. When a browser stops sending a site's session cookie on cross-site requests, the probed resource behaves as "logged out" no matter what. Chrome is the partial exception: it partitions the cache and storage by default, but it still sends third-party cookies unless you switch blocking on yourself.
What Cross-Site Login Detection Actually Is
Cross-site login detection belongs to a class of browser side channels known as XS-Leaks (cross-site leaks). The Same-Origin Policy is very good at one specific job: stopping attacker.example from reading the contents of a response from bank.example. It was never designed to stop attacker.example from requesting that response and watching how the request behaves — and behavior alone is often enough to answer a yes/no question like "is this visitor logged into bank.example right now?"
A minimal version looks like this: an attacker's page embeds a hidden <img> tag whose src points at https://bank.example/account/avatar.png. If you're logged into that bank, your browser attaches the session cookie automatically, the server returns a real image, and the load event fires. If you're logged out, the same request gets redirected to a login page or rejected outright, the response isn't a valid image, and error fires instead. The attacker never sees your account details — they only need to know which event fired. MDN's overview of cross-site leaks (XS-Leaks) catalogs this and the related techniques below as a distinct, ongoing category of browser security bugs, not a one-off exploit.
Resource and Timing Probes Against Known Endpoints
The event-based version above is the crudest form. A subtler family relies on timing instead of a clean pass/fail signal. Browsers expose the Resource Timing API (performance.getEntriesByType('resource')), which reports how long a request took and, for same-origin or Timing-Allow-Origin-permitted resources, how many bytes crossed the network. Two things make this attackable:
- Cache-timing probes. If a resource is only fetched — and therefore only cached — by users who are actively using a target site (a logged-in-only script bundle, an authenticated API response embedded in a page), then a subsequent request from the attacker's page will resolve from cache almost instantly for those users and hit the network for everyone else. The duration difference alone answers the login question.
- Frame- and request-counting. Some login-gated pages render more sub-resources than their logged-out equivalent (extra widgets, personalized modules, additional redirects). Counting how many requests or frames a page load triggers distinguishes the two states without reading any response body.
window.length— the number of frames inside a window — is one of the handful of properties the platform deliberately exposes across origins, so an attacker who opens the target in a pop-up or an iframe can read its frame count even though every other detail of that document is off limits.
Neither probe needs JavaScript access to the target origin. Everything the attacker measures happens in their own page's execution context, which is precisely why these techniques survived so long: they don't look like a same-origin violation from the browser's point of view.
Redirect- and Error-Based Detection
The redirect variant pushes the same idea further. Instead of relying on onerror alone, an attacker can pair a request with a strict Content-Security-Policy that only allows connections to the resource's expected origin, then listen for a securitypolicyviolation event. If a logged-out request gets redirected to a login page hosted on a different origin, the CSP blocks that redirect and fires a violation the attacker can observe. A logged-in request that returns the resource directly, with no redirect, never trips the policy. The presence or absence of that one event becomes the oracle — a technique documented among the error-events and CSP-based XS-Leak patterns that security researchers have cataloged across major sites over the past several years.
What makes redirect-based probing durable is that it doesn't depend on any particular bug in the target site's code — it only depends on the target site behaving differently for logged-in versus logged-out visitors somewhere in its response chain, which is true of almost any service with an authentication wall.
What This Reveals About You
A single yes/no answer — "logged into bank.example: yes" — isn't very sensitive on its own. The risk compounds when an attacker runs the same probe against a list of dozens or hundreds of known sites: banks, healthcare portals, dating apps, forums tied to specific political or religious communities, adult sites, employer intranets. The resulting bitmap of "signed in" flags is a behavioral fingerprint distinct from — and often more sensitive than — the device fingerprint covered in our browser fingerprinting guide, because it directly names the services you use rather than just narrowing down which device you're using.
That profile is immediately useful for targeted phishing: an email that correctly names your actual bank, rather than a generic "Chase or Wells Fargo, pick one" guess, is dramatically more convincing. It's also a deanonymization vector on its own — the specific combination of services someone is signed into can be nearly as identifying as a device fingerprint, and it comes with none of the technical noise that canvas or WebGL readings carry.
Browser Defenses: Partitioning, Cookie Blocking, and Fetch Metadata
The structural fix isn't patching individual leaky endpoints — sites have thousands of them — it's removing the browser behavior most of these techniques depend on: a cross-site request silently carrying the target site's session cookie.
Third-party cookie blocking and storage partitioning do exactly that. Firefox's Total Cookie Protection gives every third-party resource its own cookie jar keyed to the top-level site you're visiting, so bank.example's session cookie is simply never attached when attacker.example requests it — the probed resource looks logged-out unconditionally, regardless of your real session state. Safari's full third-party cookie blocking reaches the same end state by default rather than through a partition key. Chrome is the partial exception worth knowing about: it ships storage partitioning of its own, plus the opt-in CHIPS mechanism for the legitimate cases (embedded widgets, CDN load balancing) that still need some cross-page state — but after several postponements Google dropped the plan to turn third-party cookies off for everyone. A default Chrome window still attaches them; an Incognito window blocks them.
Cookie handling isn't the whole story, though. A cache-timing probe doesn't need a cookie on the probe request at all — it reads a cache entry your earlier, logged-in visit left behind. The defense there is a separate mechanism: browsers now partition the HTTP cache by top-level site, so a resource cached while you were on bank.example is stored under a different key than the same URL requested from a page on attacker.example, and the attacker's request always misses. Chrome and Firefox both shipped this in 2020–2021 and WebKit had partitioned network state earlier still, which is why cache probes decayed even in browsers that still send third-party cookies by default.
A complementary, server-side defense is the Fetch Metadata request headers, particularly Sec-Fetch-Site. Because these headers are browser-generated and can't be spoofed from JavaScript, a server can inspect Sec-Fetch-Site: cross-site on a request to a sensitive, authenticated endpoint and simply refuse to serve it — closing the leak at the origin that owns the data, independent of whichever browser the visitor happens to be using. The two defenses reinforce each other: partitioning protects you even against sites that haven't adopted Fetch Metadata, and Fetch Metadata protects visitors on browsers that still send third-party cookies by default.
Putting It Together
Cross-site login detection is a cousin of the passive, event-driven observation techniques covered in our bot detection guide — both rely on watching load timing, error events, and response behavior rather than reading anything an attacker isn't supposed to see. And it compounds with device fingerprinting rather than replacing it: knowing which device and which accounts both point at the same visitor is a stronger signal than either alone, which is why understanding how fingerprint signals combine matters even when the specific leak here is about login state, not hardware.
The good news is that this is one of the few tracking techniques where the fix genuinely lives in the browser rather than in your own habits. On a current Firefox or Safari with default protections on, the cookie-dependent probes above are already dead — the session cookie they rely on never leaves the site that set it. On Chrome the cache-timing probes are closed by default too, but the cookie-based ones stay open until you enable third-party cookie blocking yourself, which makes that one setting the highest-value change available against this whole class of leak.
Login state itself isn't something a page can show you — the probe runs on someone else's site, and by design you never see its answer. What you can inspect is the rest of the surface an attacker would combine it with: BrowserInsight's fingerprint check reports the canvas, WebGL, font, and storage signals your browser currently exposes, all measured in your browser and never sent anywhere for analysis.
Frequently Asked Questions
Can a website really tell if I'm logged into my bank just by visiting a page?
It used to be reliably possible with the techniques above. In a browser that blocks third-party cookies by default — current Firefox and Safari both do — your bank's session cookie is no longer attached to a cross-site request, so the probed resource behaves as logged-out regardless of your real session, and the bank doesn't have to change anything. Chrome is the remaining gap: cache and storage partitioning are on by default and kill the timing probes, but third-party cookies are still sent unless you turn blocking on in privacy settings or browse in Incognito.
Does private/incognito browsing stop login detection?
Mostly, but for an indirect reason: you usually aren't signed into anything in a private window, so every probe honestly answers "logged out". Beyond that, private mode doesn't change the rules — cross-site cookie behavior inside an active private session follows the same third-party cookie and partitioning settings as normal browsing. The exception worth knowing is Chrome, which blocks third-party cookies by default in Incognito but not in a normal window, so there the private window really does close probes a regular one leaves open.
Is this the same thing as browser fingerprinting?
No, and the distinction matters. Fingerprinting identifies your device from technical attributes like fonts, GPU output, and screen geometry. Login detection identifies which accounts you hold, using the browser's cookie-handling behavior rather than any device attribute. An attacker with both can tie a specific device to a specific set of real-world services — each signal is more powerful combined with the other than alone.
Can a website fix this on its own, without waiting for browsers?
Partially. Adopting Fetch Metadata headers lets a site reject cross-site requests to authenticated endpoints outright, which closes the leak for every visitor regardless of browser. But it requires that specific site to implement it correctly across every sensitive endpoint, which is why browser-side partitioning — protecting visitors even against sites that haven't done that work — has become the primary line of defense.
