Which logs show evidence of cross-site leaks (XS-Leaks)?

Which logs are most useful for spotting XS-Leaks?

The best evidence usually comes from the places where cross-origin behaviour is observable, not from one single log source. Browser-side telemetry can show suspicious navigation, embedding, or resource loading patterns, while web server access logs and application logs can reveal repeated probes, origin-dependent responses, and timing or size variation. CDN logs can add edge-level context when attacks are distributed or high volume.

For teams already maintaining a client-side security programme, the same logging and review discipline that helps with script abuse also helps here; the Client-Side Security Guide is useful background when you are correlating browser activity with server-side traces.

What patterns in logs suggest cross-site probing?

XS-Leaks rarely look like a single obvious exploit. In logs, the strongest clues are repeated cross-origin requests from the same client or session, requests that vary only slightly across origins, and sequences that appear to test whether a user is logged in, logged out, or otherwise stateful. Unusual differences in response size, redirects, cache behaviour, or request timing are especially important because side channels are often what the attacker is measuring.

Application and access logs become more valuable when you can compare them against the expected behaviour of normal users. A request that is harmless in isolation may become suspicious when it appears in a burst, from multiple origins, or in a pattern that tracks a protected state transition such as authentication, account presence, or profile visibility. That is why log correlation across sessions and user agents matters more than any one event line.

If you are hunting for broader client-side attack patterns at the same time, Web Application Attacks Guide gives useful context for how web abuse often combines request patterns, browser behaviour, and application response differences.

How should defenders investigate suspected XS-Leaks?

Start by grouping logs around the same origin, session, IP range, and user agent, then look for repeated requests that differ only in the target origin or the authenticated state of the user. Compare the response metadata, not just the status code. Content length, cache hits, redirect chains, and latency deltas can all be meaningful when the leak depends on a measurable browser side channel.

It also helps to preserve enough browser-side evidence to explain what happened before and after the server interaction. When the attack relies on embedded resources, redirects, or timing-sensitive checks, the browser trace may be the only place where the full sequence is visible. Server logs alone can miss the reason a benign-looking request was repeated so often or why a response pattern was useful to the attacker.

Where browser-side probing is part of a wider client-side abuse campaign, Cross-Site Scripting (XSS) Prevention Guide is a useful adjacent reference because the same environment often needs combined defences and shared investigation workflow.

Risk and Threat Considerations

XS-Leaks are dangerous because they turn ordinary browser and web infrastructure into an oracle. Even without obvious payload delivery, an attacker can infer secrets about login state, account existence, or user attributes by measuring behaviour differences that your logs only show indirectly. That makes weak correlation, aggressive caching, and incomplete visibility especially risky.

Failure mechanism: The attacker induces cross-origin requests, embeds resources, or repeats navigations until response timing, size, redirect, or cache differences expose a hidden state. If logging is fragmented across browser, app, CDN, and origin layers, the signal can look innocuous in each individual system.

Impact: Sensitive state can be inferred without direct content theft, which can support reconnaissance, account enumeration, targeted phishing, or follow-on abuse. A mature investigation therefore needs cross-layer correlation, not just incident review from the application server alone.

Practitioner Guidance

What to verify: Confirm that your logs can be joined by session, origin, request path, user agent, and timestamp with enough precision to detect small timing or size differences. If any one of those dimensions is missing, XS-Leak investigation becomes much less reliable.

What to measure: Track whether repeated requests from the same client produce materially different responses when the authenticated state or origin changes. That comparison is often more useful than raw request volume.

Practitioner takeaway: Treat XS-Leak hunting as a correlation problem across layers. The logs that matter most are the ones that let you compare normal and abnormal cross-origin behaviour, not just the ones that record the final request.

Related resources from NHI Mgmt Group

• Cross-Site Leaks (XS-Leaks)
• Which logs show evidence of fast-flux DNS?
• Which logs show evidence of Modify Cloud Compute Infrastructure?
• Which logs show evidence of Create Cloud Instance?