MCP server font-display security — FOIT flash-of-invisible-text, font swap layout shift, and symbol font substitution attacks on consent disclosures

How font-display works — and why it is an attack surface

When a browser encounters a @font-face rule and begins downloading the font file, it must decide what to show the user for text that depends on that font. Two periods govern this decision:

• Block period: The interval immediately after the font is first needed. During this period, text using the web font is rendered with invisible glyphs — the text occupies its layout space and affects document flow, but its pixels are painted transparently. If the font loads before the block period expires, the browser swaps immediately and text becomes visible. If not, the block period ends and the browser applies the fallback font.
• Swap period: The interval after the block period ends. During this period, if the font finally loads, the browser will swap the fallback text to the web font (causing a layout shift if the metrics differ). After the swap period expires, the fallback font is kept permanently even if the web font eventually loads.

The five font-display values configure the duration of these two periods differently:

• auto — browser default; typically similar to block
• block — block period up to 3 seconds (text invisible); swap period infinite
• swap — block period approximately 0ms (immediate fallback); swap period infinite
• fallback — block period approximately 100ms; swap period 3 seconds, then permanent fallback
• optional — block period approximately 100ms; swap period 0ms (if font not cached, never swaps)

The critical detail for attackers: during the block period, the disclosure element's textContent, the DOM structure, and the accessibility tree all return the correct permission text. Only the rendered pixels are invisible. No standard DOM property, no getComputedStyle() call, and no screen reader check distinguishes "text invisibly rendered during FOIT" from "text normally rendered in a loaded font." An audit that does not simulate the font-loading lifecycle will not detect the attack window.

Attack 1 — font-display:block creating a 3-second FOIT window

The most direct attack uses font-display:block and an artificially slow-loading font server. The block period — up to 3 seconds — creates a Flash of Invisible Text (FOIT) window during which the disclosure text is present in the DOM but invisible on screen. If the consent dialog presents an Accept button during this window, a user can click Accept without ever seeing the disclosure text.

@font-face {
  font-family: 'ConsentFont';
  src: url('https://fonts.attacker.com/slow-font.woff2');  /* artificially slow load */
  font-display: block;  /* up to 3-second block period: text is invisible */
}
.mcp-disclosure {
  font-family: 'ConsentFont', sans-serif;
  /* during block period: disclosure text is invisible (FOIT) */
  /* textContent, DOM, accessibility tree all return correct permission text */
  /* only the rendered pixels show nothing — the disclosure appears blank */
}

Detection requires more than checking font-display values in the stylesheet: the audit must also verify whether the font source URL responds quickly. A font that loads in 50ms poses no practical FOIT risk. A font that takes 4 seconds — whether due to server throttling, geographic latency, or deliberate delay — creates a real attack window. SkillAudit checks both the declared font-display value and the network response time of each font src URL in audit sandbox conditions.

Attack 2 — Never-loading font URL keeping disclosure invisible

A more reliable variant of the block-period attack uses a font source URL that returns HTTP 404 or that never responds at all. The browser enters the block period at page load and waits for the font. On fast networks, the 404 response arrives quickly, the font fails to load, and the block period ends after its nominal 3 seconds, swapping to the system sans-serif fallback. But on slow connections, the 404 response itself may take longer than 3 seconds to arrive — extending the FOIT window beyond what the font-display:block nominal limit suggests.

@font-face {
  font-family: 'ConsentText';
  src: url('https://cdn.example.com/nonexistent-font.woff2');  /* 404 */
  font-display: block;
}
.mcp-disclosure {
  font-family: 'ConsentText', sans-serif;
}

Detection: for every @font-face rule applied to a consent disclosure element, SkillAudit fetches the font src URL from the audit sandbox and checks the HTTP response status. URLs returning 4xx responses or connection timeouts on fonts applied to disclosures are flagged immediately. The audit also simulates the disclosure rendering in a throttled-network sandbox to measure the actual FOIT duration in slow-network conditions.

Attack 3 — font-display:fallback + metric-mismatch overflow

This attack targets the swap period rather than the block period, and exploits the difference in character metrics between the loaded web font and its fallback. With font-display:fallback, the block period is only 100ms — too short to be an effective FOIT window. Instead, the attack relies on the fact that the fallback font and the web font have very different character widths. When the disclosure is rendered in the fallback font (Arial Black), the text fits within the container. When users have the web font cached from a prior page load, the wider web font causes the disclosure text to overflow an overflow:hidden container — making it invisible for users who have visited the page before.

@font-face {
  font-family: 'FallbackTrap';
  src: url('https://very-slow-server.invalid/font.woff2');  /* connection refused / timeout */
  font-display: fallback;
  /* block period: 100ms — invisible text for 100ms */
  /* swap period: 3 seconds — if font loads within 3s, swap; otherwise use fallback forever */
}
.mcp-disclosure {
  font-family: 'FallbackTrap', 'Arial Black', sans-serif;
  /* 'Arial Black' is the fallback — metrics very different from web font metrics */
}

Detection: SkillAudit checks whether the fallback font metrics differ significantly from the loaded web font metrics for fonts applied to disclosure elements. The audit simulates rendering the disclosure element with both the fallback font and the loaded font, measures the resulting text dimensions, and flags cases where the text overflows an overflow:hidden container in one scenario but not the other. A character width ratio of more than 1.3× between the web font and its fallback on disclosure elements is flagged as a metric-mismatch risk.

Attack 4 — Symbol font substituting permission text with glyphs

This attack does not rely on font loading delays at all. Instead, it uses a @font-face rule with an inline base64 data URI to load a custom font in which standard ASCII characters are mapped to Private Use Area symbol glyphs — a technique equivalent to applying Wingdings to the disclosure text. The disclosure element's textContent contains the correct English permission text. The rendered output is a sequence of unreadable dingbat symbols.

@font-face {
  font-family: 'PermissionFont';
  src: url('data:font/woff2;base64,...');  /* inline base64 — a Wingdings-style symbol font */
  font-display: swap;
}
.mcp-disclosure {
  font-family: 'PermissionFont';
  /* "READ EXECUTE DELETE access permissions requested" renders as */
  /* "♔♖♘♙ ♕♗♞♙♔♕ ♘♙♔♕♗♘ ♙♔♙♕♔♗♙ ♕♙♔♕♗♙♙♔♔♗♙♘♙♕ ♔♙♕♚♙♔♗♕♙♘" */
  /* the DOM has the correct ASCII text; the symbol font renders unreadable glyphs */
}

Detection requires loading the font and inspecting its character-to-glyph mapping. SkillAudit extracts inline data URI fonts and loads them in a font analysis sandbox. For each font applied to a consent disclosure element, the audit checks whether the glyphs for common ASCII characters (Unicode range 0x41–0x7A: uppercase A through lowercase z, plus space and digits) are alphabetic letterforms or non-alphabetic symbol glyphs. Fonts where more than 20% of the standard ASCII range maps to symbol or Private Use Area glyphs are flagged as symbol substitution risks. Additionally, SkillAudit renders the disclosure element in the audit sandbox and compares the pixel output against a reference rendering using system sans-serif — significant visual divergence triggers a visual mismatch alert.

Summary table

Detection checklist

Detecting all four attack variants requires a multi-layer audit that covers both static CSS analysis and dynamic font-loading simulation. SkillAudit's methodology covers the following controls:

• Enumerate all @font-face rules applied to consent disclosure elements. Walk the CSS cascade for each disclosure element and collect every @font-face rule in the matched font family list, including fallback entries. This includes rules in stylesheets, inline style attributes, and injected style tags.
• Fetch font src URLs and check HTTP status. For each @font-face src URL (excluding data URIs, which are handled separately), issue a network request from the audit sandbox and record the HTTP response status and response time. Flag 4xx responses and connection timeouts on fonts applied to disclosure elements. Record response time for all 2xx responses — slow responses (over 1 second) on disclosure fonts are flagged as FOIT-risk candidates.
• Flag font-display:block on fonts applied to disclosures. Any @font-face rule with font-display:block applied to a consent disclosure element is a potential FOIT attack surface. Flag the finding and correlate with the font src URL response time to assess actual risk duration.
• Extract and analyze inline data URI fonts. For @font-face rules with src: url('data:font/...'), extract the base64 payload, decode it, and load the font in a character analysis sandbox. Map ASCII code points 0x20–0x7E to their rendered glyphs and check whether the glyph outlines match alphabetic letterforms. Flag fonts where common ASCII characters map to non-alphabetic symbol glyphs.
• Render the disclosure element and compare pixel output. In the audit sandbox, render the disclosure element with all @font-face fonts loaded and capture a pixel snapshot. Render the same element's textContent using the system sans-serif font and capture a reference snapshot. Compute the visual similarity score between the two. Flag significant visual divergence (similarity below 70%) as a potential symbol substitution attack.
• Check fallback font metrics versus web font metrics. For each @font-face applied to a disclosure, measure the character advance widths for the web font and its declared CSS fallback. Simulate rendering the full disclosure text in both fonts at the element's computed width. If the web font causes overflow where the fallback does not (or vice versa) and the element has overflow:hidden, flag the metric-mismatch as a TOCTOU overflow risk.

SkillAudit findings