History Stealing

What history stealing is

History stealing is a browser-side privacy attack that exploits the way visited and unvisited links are rendered or measured. By observing styling, timing, or other response differences tied to specific URLs, an attacker can infer which pages a user has likely visited without directly reading the browser history store.

How history stealing works

The attack depends on the browser revealing a side effect of the user’s browsing state. Classic examples include CSS selectors for visited links, script-driven timing checks, and other probes that behave differently when a target URL is in history. The key issue is not access to the history database itself, but leakage through observable rendering or interaction differences.

That makes history stealing a form of privacy inference, not a simple data extraction problem. Even when modern browsers reduce obvious visited-link leakage, the broader lesson remains that shared rendering behavior can become an oracle if a page can test many candidate URLs quickly enough.

Why history stealing is dangerous

Browsing history can expose sensitive interests, internal research, health, finance, political activity, or account-related pages. If an attacker can infer those visits at scale, the result is a privacy breach even without credential theft. The danger is strongest when the visited pages reveal habits, business context, or security-sensitive destinations that a user would not expect a website to learn.

The attack is especially concerning because it is low noise and can be embedded into ordinary web content. A malicious page may not need special browser privileges if it can trigger enough probes and distinguish subtle differences in response or rendering.

Defensive controls and browser hardening

Defence relies on reducing what a page can observe and limiting how much browsing state leaks into page-visible behavior. Modern browser protections, such as restricting visited-link styling to a narrow set of properties and isolating timing behavior, are designed to remove the oracle the attack depends on.

At the site and platform level, teams should avoid assuming that link styling, script timing, or browser rendering differences are benign. Security testing should include privacy-leak review of any feature that varies based on prior user state, because a small observable difference can become a history probe.

For browser and application owners, the practical goal is to make visited state indistinguishable from unvisited state to untrusted content. Where that is not possible, reducing URL predictability and minimizing sensitive link exposure lowers the usefulness of the attack.

Detection and response considerations

History stealing is often difficult to detect from the user’s side because the probe can look like normal page activity. Defensive monitoring therefore focuses more on browser behavior, privacy regression testing, and suspicious pages that enumerate many candidate URLs in rapid succession than on a single clear alert.

After exposure, the primary response is usually privacy containment rather than incident cleanup. Users may need to clear browsing state, review sensitive exposure paths, and treat any page that tested history as potentially aware of their browsing interests. The right response depends on whether the probe was purely inferential or part of a broader malicious page.

Related resources from NHI Mgmt Group

• How should teams respond when a GitHub personal access token is exposed in an AI chat history?
• Why do secrets in Git history create long-term risk?
• How should organisations respond when a secret appears in Git history?
• Who is accountable when an exposed AI agent gateway leaks secrets and chat history?