MCP server Back/Forward Cache (BFCache) security — auth state persistence, session leakage, and Cache-Control: no-store defense

How BFCache works across Chrome, Firefox, and Safari

All three major browser engines implement BFCache, though with different eligibility rules. When the user navigates away from a page, the browser evaluates whether the page qualifies for BFCache. If it does, the browser suspends the page's JavaScript execution and serializes the full execution context — including the heap — into an in-memory cache slot. When the user presses back or forward, the browser restores the page from this cache slot rather than re-fetching the URL.

Two lifecycle events bracket the BFCache transition:

• pagehide — fires just before the page is frozen into BFCache (or unloaded). The event's persisted property is true if the page is being frozen for BFCache, false if it is being unloaded permanently.
• pageshow — fires when the page becomes visible again. The event's persisted property is true if the page was restored from BFCache, false if it was loaded fresh from the network.

// Detecting BFCache freeze and restoration

window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    // Page is being frozen into BFCache — NOT unloaded
    // Any sensitive state in memory will survive here
    console.log('Page frozen into BFCache — credentials and tool output persist in memory');
  } else {
    // Normal unload — page is being destroyed
    console.log('Page is being unloaded — memory will be freed');
  }
});

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Page was restored from BFCache — no network request was made
    // JavaScript heap is exactly as it was when the page was frozen
    console.log('Page restored from BFCache — session state may be stale');

    // DEFENSE: Re-validate session on BFCache restoration
    fetch('/api/session/validate', { credentials: 'include' })
      .then(res => {
        if (!res.ok) {
          // Session is no longer valid — redirect to login
          window.location.replace('/login');
        }
      });
  }
});

Testing whether a navigation was served from BFCache

The Navigation Timing Level 2 API exposes the navigation type, which distinguishes BFCache restorations from normal navigations. Security engineers can use this to verify whether logout flows correctly exclude pages from BFCache or whether a given page is BFCache-eligible.

// Test whether the current page load was served from BFCache
// Useful for verifying that logout and sensitive pages are excluded

function wasRestoredFromBFCache() {
  const navEntries = performance.getEntriesByType('navigation');
  if (navEntries.length === 0) return false;
  // type === 'back_forward' means the page was re-navigated via back/forward
  // Combined with event.persisted === true in pageshow, confirms BFCache restoration
  return navEntries[0].type === 'back_forward';
}

// Run on pageshow to detect BFCache-restored back/forward navigations
window.addEventListener('pageshow', (event) => {
  const fromBFCache = event.persisted && wasRestoredFromBFCache();
  if (fromBFCache) {
    console.warn('BFCache restoration detected — re-validate all sensitive state');
  }
});

Attack surface 1: sensitive MCP tool output persists in the BFCache copy

MCP tools regularly output sensitive data into the browser rendering context: authentication tokens from an OAuth tool, private messages from a messaging integration, file contents from a file-access tool, or user PII from a CRM integration. When the user navigates away from the page displaying this output, BFCache freezes the page — including all that sensitive data — into memory. The data is not cleared, not invalidated, and not re-validated with the server.

Attack surface 2: logout does not invalidate the BFCache copy

A common logout implementation sends a POST /logout request, invalidates the session cookie on the server, and redirects to the login page. This correctly ends the server-side session. However, it does not evict the BFCache entry for the previously authenticated page. If the attacker can trigger a back navigation immediately after logout — by using JavaScript's history.back(), a crafted link, or physical access to the browser — they land on the BFCache-restored authenticated page.

// Insecure logout implementation — BFCache entry survives
async function insecureLogout() {
  await fetch('/api/logout', { method: 'POST', credentials: 'include' });
  // Server invalidates session cookie. But the previous authenticated page
  // is still frozen in BFCache and will be served on back navigation.
  window.location.href = '/login';
}

// Secure logout implementation — prevents BFCache restoration of auth pages
async function secureLogout() {
  await fetch('/api/logout', { method: 'POST', credentials: 'include' });

  // Option 1: Navigate to login AND set a pageshow handler that re-checks auth
  // This approach works even if some pages are already in BFCache

  // Option 2: The server must respond with Cache-Control: no-store on all
  // authenticated pages — BFCache respects this header and excludes the page.
  // This is the most reliable defense (see Defenses section below).

  window.location.replace('/login'); // replace() removes current page from history
}

The unload event handler: cross-browser inconsistency

A widely-known technique for disabling BFCache is registering an unload event handler. Pages with active unload listeners are excluded from BFCache in Firefox and Safari because those browsers cannot guarantee the handler won't have observable side effects on restoration. However, Chrome has deprecated the unload event and no longer uses its presence as a BFCache eligibility criterion — meaning this technique provides false security for Chrome users.

// Adding an unload handler disables BFCache in Firefox and Safari
// but NOT in Chrome (Chrome deprecated unload event in 2024+)
// Do NOT rely on this as your primary BFCache defense

window.addEventListener('unload', () => {
  // Firefox and Safari exclude this page from BFCache
  // Chrome ignores the unload handler for BFCache eligibility
});

The correct defense: Cache-Control: no-store

The Cache-Control: no-store response header is the most reliable cross-browser mechanism to exclude a page from BFCache. Chrome, Firefox, and Safari all respect this directive by refusing to store the page in BFCache. MCP server renderer endpoints that return authenticated pages or pages that may display sensitive tool output should include this header.

# Server-side response headers for MCP renderer pages that handle sensitive tool output
# Include on any route that may display authenticated content or MCP tool results

# Express.js / Node.js
app.use('/mcp-chat', (req, res, next) => {
  // no-store excludes the page from BFCache across Chrome, Firefox, and Safari
  res.setHeader('Cache-Control', 'no-store');
  // Also prevent intermediate proxy caching
  res.setHeader('Pragma', 'no-cache');
  next();
});

# Python (Flask)
@app.after_request
def add_cache_headers(response):
    if request.path.startswith('/mcp'):
        response.headers['Cache-Control'] = 'no-store'
    return response

# Nginx config
location /mcp-chat {
    add_header Cache-Control "no-store" always;
    proxy_pass http://backend;
}

BFCache eligibility criteria summary

Defenses

Findings SkillAudit reports

Related guides: MCP server caching security, Session management security, Browser storage security.