Leakuidator+: Fighting Cross-Site Leak Attacks at the Browser Extension Layer

Hook

Your browser makes over 100 cross-site requests per page load, and attackers can use the success or failure of those requests to figure out which accounts you're logged into—without accessing a single cookie.

Context

Cross-site leak attacks represent a sophisticated threat that exists in the gray area between legitimate web functionality and exploitable side-channels. Unlike traditional XSS or CSRF attacks, these vulnerabilities don't require injecting malicious code or forging requests. Instead, they exploit fundamental browser behaviors: timing differences when loading cached versus uncached resources, error messages when requests succeed versus fail, or the observable state changes that occur when a resource is available versus protected.

Consider a scenario: You visit a website that embeds an image tag pointing to your private GitHub repository. If the image loads, the site knows you have access to that repository. If it fails, you don't. No cookies were stolen, no same-origin policy was violated, yet you've been deanonymized. This class of attacks—sometimes called XS-Leaks—has been documented since the early 2010s but remains underaddressed by mainstream browser security features. Leakuidator+ emerged as a research project to give users granular control over these cross-site requests, operating as a network-level gatekeeper that flags suspicious patterns before they can leak information.

Technical Insight

Leakuidator+ positions itself in the browser's request pipeline using the WebExtensions API's webRequest interceptor, specifically the onBeforeRequest event. This gives the extension visibility into every outbound HTTP request before it leaves the browser, allowing it to analyze the destination domain against a curated list of sensitive targets—storage providers like Dropbox and Google Drive, social platforms like Facebook and Twitter, and code repositories like GitHub and GitLab.

The core detection logic relies on domain classification using the Public Suffix List, a Mozilla-maintained dataset that distinguishes between organizational boundaries (github.com versus microsoft.com) rather than just top-level domains. Here's how the request interception pattern works in practice:

// Simplified request interception logic
chrome.webRequest.onBeforeRequest.addListener(
  function(details) {
    const initiatorDomain = extractDomain(details.initiator);
    const targetDomain = extractDomain(details.url);
    
    // Check if domains are cross-site using public suffix list
    if (!isSameSite(initiatorDomain, targetDomain)) {
      // Check if target is a protected domain
      if (isProtectedDomain(targetDomain)) {
        // Check user's stored preferences
        const preference = getUserPreference(initiatorDomain, targetDomain);
        
        if (preference === 'block') {
          return {cancel: true};
        } else if (preference === 'allow') {
          return {}; // Allow request
        } else {
          // No preference: show user prompt
          return showUserPrompt(details);
        }
      }
    }
    return {}; // Allow by default
  },
  {urls: ["<all_urls>"]},
  ["blocking"]
);

The extension implements two detection modes that affect the sensitivity of the domain matching. In Relaxed mode, the extension looks for cross-site requests at the organizational level—any request from nytimes.com to facebook.com would trigger a warning. In Exact mode, the granularity increases to the full domain level, meaning subdomain differences also count as cross-site (www.example.com versus api.example.com would be flagged separately).

The user-facing component presents a modal overlay when suspicious requests are detected, displaying the initiating site, the target domain, and the resource being requested. Users can choose to allow once, block once, or remember their decision for future visits. This remembered preference system stores mappings in browser local storage:

// Preference storage structure
{
  "preferences": {
    "news.ycombinator.com->github.com": "allow",
    "sketchy-site.com->dropbox.com": "block",
    "forum.example.com->twitter.com": "allow"
  }
}

The architecture also includes punycode handling through the punycode.js library to properly process internationalized domain names (IDN), preventing attackers from using visually similar Unicode characters to bypass domain matching. For example, a domain using Cyrillic 'а' instead of Latin 'a' would be normalized to its ASCII representation before comparison.

One particularly clever aspect of the implementation is its handling of subresource types. The extension differentiates between navigation requests (clicking a link), image loads, script includes, and XMLHttpRequests, applying different risk scores. A navigation to GitHub is less suspicious than an invisible image probe to check GitHub access, so the extension can tune its warnings accordingly. This contextual awareness reduces false positives while maintaining protection against the most common attack vectors.

Gotcha

The primary limitation of Leakuidator+ is its reliance on user decision-making in a domain where most users lack the context to make informed choices. When a popup appears asking whether to allow news.ycombinator.com to request resources from github.com, how should a typical user respond? Is this request legitimate (perhaps HN is loading GitHub avatars) or malicious (probing for private repository access)? Without deep understanding of cross-site leak attack patterns, users will either allow everything (defeating the purpose) or block everything (breaking legitimate functionality). This creates decision fatigue similar to early popup blockers or certificate warnings that users learned to click through reflexively.

The second major issue is staleness. The protected domain list was last updated in June 2022 according to repository commits, meaning newly popular services or rebranded platforms won't be recognized as sensitive targets. The extension also doesn't update its domain lists automatically—users would need to manually update the extension to get refreshed protection rules. Combined with just 12 GitHub stars and no clear indication of active maintenance, potential users face legitimate questions about whether this tool will keep pace with evolving web threats. Modern browsers have also started implementing their own cross-site leak mitigations through SameSite cookies, Cross-Origin-Resource-Policy headers, and partitioned caches, potentially reducing the need for a dedicated extension while simultaneously rendering some of Leakuidator+'s detection patterns obsolete.

Verdict

Use if: You're a security researcher studying XS-Leak attack patterns, a privacy advocate with a sophisticated threat model who needs visibility into cross-site request patterns, or you're building educational materials about browser security and need a demonstration tool for side-channel attacks. The extension provides valuable transparency into a genuinely underappreciated attack vector. Skip if: You're looking for practical, everyday privacy protection—mainstream extensions like uBlock Origin provide broader coverage with less friction, and modern browser features like Enhanced Tracking Protection increasingly address cross-site leaks by default. The dated codebase, low adoption numbers, and high interaction overhead make this more of a proof-of-concept than a production-ready privacy tool for most developers.