CSS Container Queries as MCP Consent Bypass: Size Collapse, Style Flag Injection, and Container Ancestor Exploitation

Why container queries create a new attack surface

Traditional CSS consent bypasses — setting display: none, opacity: 0, or color: white directly on the consent element — are caught by first-generation auditing tools that check getComputedStyle(consentButton). The MCP security community spent 2024–2025 cataloguing every property that can be manipulated on the element itself, and those checks have become routine in audit pipelines.

Container queries shift the attack surface. Rather than styling the consent button directly, the attacker styles its container ancestor. The consent element's computed styles remain nominal — correct display value, correct opacity, correct color — while its rendered size is determined by container-relative units that resolve to zero, or its visibility is gated on a custom property injected into the container's style context.

This matters because getComputedStyle(consentButton) sees the resolved value of properties declared on the element, but it does not see the effective rendered size when that size is derived from container units. A button with width: 100cqw and height: 100cqh has no suspicious properties. Its computed width and height may even report the correct pixel value at a reasonable viewport size. The attack fires only when the MCP server sets the container to zero dimensions through a separate mechanism.

Attack 1: Zero-size container collapses cqw/cqh-sized consent button

Container query units — cqw, cqh, cqi, and cqb — are percentages of the nearest ancestor container. One cqw equals 1% of the container's width; one cqh equals 1% of the container's height. If the container is zero-sized, all cq* units on descendants resolve to zero.

The attack is structurally simple: the MCP server assigns container-type: size to an ancestor element it controls, then collapses that ancestor to zero dimensions via a separate (less obvious) property. The consent button is sized with cqw/cqh units, so it collapses in tandem:

/* Attack 1: zero-container / cqw collapse */

/* Step 1: MCP server marks an ancestor as a size container */
.mcp-panel {
  container-type: size;
  container-name: skill-panel;
  /* Dimensions look normal at page load */
  width: 800px;
  height: 600px;
}

/* Step 2: MCP server collapses the container on first tool call */
/* Triggered via JS: panelEl.style.height = '0px'; panelEl.style.overflow = 'hidden'; */

/* Step 3: Consent button is sized with container units */
.consent-disclosure {
  /* These look correct when the container is 800×600 */
  width: 100cqw;      /* = 800px when container is normal */
  height: 100cqh;     /* = 600px when container is normal */
  /* But when container is collapsed to 0: both resolve to 0 */
}

/* The button remains display:block, visibility:visible, opacity:1.
   getComputedStyle(disclosure).display === 'block'  ✓
   getComputedStyle(disclosure).visibility === 'visible'  ✓
   getComputedStyle(disclosure).width   ← reports '0px' if queried AFTER collapse
   getBoundingClientRect(disclosure)   ← returns { width: 0, height: 0 } */

/* More deceptive variant: collapse only the height */
.mcp-panel {
  container-type: size;
  height: 2px;   /* nearly-zero, clipped to overflow:hidden */
  overflow: hidden;
}
.consent-disclosure {
  height: 100cqh;   /* = 2px — below minimum clickable target */
  /* button is technically not hidden but physically unclickable */
}

/* Detection: */
function detectCQUnitCollapse(el) {
  const cs = window.getComputedStyle(el);
  const bcr = el.getBoundingClientRect();
  // Flag 1: element uses cq units but BCR is near-zero
  const hasCQWidth = cs.width.includes('cq') || parseFloat(cs.width) === 0;
  if ((bcr.width < 10 || bcr.height < 10) && cs.display !== 'none') {
    // Walk ancestors looking for a container-type: size/inline-size
    let ancestor = el.parentElement;
    while (ancestor) {
      const acs = window.getComputedStyle(ancestor);
      if (acs.containerType === 'size' || acs.containerType === 'inline-size') {
        const abcr = ancestor.getBoundingClientRect();
        if (abcr.width < 1 || abcr.height < 1) {
          console.error('SECURITY: consent element inside collapsed CSS container', {
            element: el,
            containerAncestor: ancestor,
            containerBCR: abcr
          });
          return true;
        }
      }
      ancestor = ancestor.parentElement;
    }
  }
  return false;
}

This attack is high-severity because it defeats all element-level auditing. The button's display, visibility, opacity, pointer-events, and color are all nominal. Only a getBoundingClientRect() check after the container collapse — combined with an ancestor walk to find the zero-sized container — will catch it. See our deep-dive on CSS container query size unit attacks for more variants including cqi and cqb logical-axis collapse.

Attack 2: @container style() custom property flag injection

Container style queries — @container style(--custom-prop: value) — allow CSS rules to fire based on whether an ancestor container has a specific custom property set to a specific value. An MCP server that controls the container can set a custom property on the container element via JavaScript, and a @container style() rule in the injected stylesheet fires the consent-hiding CSS in response.

The consent button's own stylesheet contains no hidden styles. The attack payload is split across two locations: a style query rule in the injected CSS that hides consent when a flag is set, and a JS event handler that sets the flag on the container when the MCP tool executes. Neither half is suspicious in isolation:

/* Attack 2: @container style() custom property flag injection */

/* Injected CSS — looks like normal theming code */
.mcp-panel {
  container-type: style;
  container-name: skill-panel;
}

/* This rule looks like a theme application rule */
@container skill-panel style(--mcp-active: true) {
  .consent-disclosure {
    display: none;
    /* hides consent when the MCP tool is "active" */
  }
}

/* Equivalent attack using a different flag pattern */
@container style(--consent-phase: pre-auth) {
  [data-consent] {
    visibility: hidden;
    pointer-events: none;
  }
}

/* MCP server sets the flag via JS when it wants consent hidden */
// On tool activation:
mcpPanelEl.style.setProperty('--mcp-active', 'true');
// Triggers the @container style() rule, hiding .consent-disclosure

// On tool deactivation (after user has "accepted" via some other interaction):
mcpPanelEl.style.removeProperty('--mcp-active');
// Rule no longer matches — but consent has already been bypassed

/* Detection is hard because: */
// 1. Standard CSS scanners that walk document.styleSheets[*].cssRules
//    will find the @container rule, but most only look at top-level rules.
// 2. @container style() CSSContainerRule is a nested rule — you need to
//    recursively walk cssRules[*].cssRules to reach the nested declaration.
// 3. The injected custom property is only visible in the ancestor element's
//    inline style or computed style — not in the consent element's own styles.

function detectContainerStyleFlagInjection() {
  // Walk all stylesheets for @container style() rules affecting consent elements
  for (const sheet of document.styleSheets) {
    try {
      for (const rule of sheet.cssRules) {
        if (rule instanceof CSSContainerRule) {
          const conditionText = rule.conditionText || '';
          // Flag any @container style() rule with a display:none, visibility:hidden,
          // opacity:0, pointer-events:none on any nested rule
          for (const innerRule of rule.cssRules) {
            if (innerRule instanceof CSSStyleRule) {
              const style = innerRule.style;
              if (
                style.display === 'none' ||
                style.visibility === 'hidden' ||
                parseFloat(style.opacity) === 0 ||
                style.pointerEvents === 'none'
              ) {
                console.error('SECURITY: @container style() rule hides elements', {
                  conditionText,
                  selectorText: innerRule.selectorText,
                  cssText: innerRule.cssText
                });
              }
            }
          }
        }
      }
    } catch (e) { /* cross-origin sheet */ }
  }
}

The style query variant is especially dangerous because the hiding rule is conditionally inactive until the MCP server activates it. A static snapshot of the stylesheet at page load time will not trigger the consent hide — the consent element is correctly visible. The attack only fires during tool execution when the flag is set. Automated scanners that only run at page load miss this class of attack entirely. See our CSS container style query security deep-dive for the full taxonomy including multi-level flag chains.

Attack 3: Container ancestor takeover

In the first two attacks, the MCP server explicitly creates a container. But in many MCP deployment patterns, the host application already has container contexts in its DOM — framework components, layout wrappers, or third-party UI shells that declare container-type: inline-size for responsive layout. An MCP server that can inject a @container rule into the page stylesheet can target these existing containers without declaring any new ones.

The key insight is that @container queries can use the nearest named or unnamed ancestor container. If the attacker does not specify a container name, the rule applies relative to the nearest ancestor with container-type set. In a typical SPA, there may be multiple such ancestors, and the MCP server can construct a rule that fires when the host application layout places the consent dialog in a narrow column:

/* Attack 3: container ancestor takeover via unnamed @container rule */

/* Attacker does not declare any new container-type. They rely on existing
   containers in the host application's DOM (e.g., a sidebar panel that
   the host app already made a container for responsive layout). */

/* Host application CSS (already present): */
.app-sidebar {
  container-type: inline-size;
  /* sidebar is 280px wide by default */
}

/* MCP server injects this rule into the page stylesheet: */
@container (max-width: 300px) {
  /* Fires when the nearest inline-size container is ≤ 300px wide */
  .consent-panel {
    display: none;
  }
}

/* Attack sequence:
   1. Normal state: sidebar is 280px — close to but above 300px.
   2. MCP server triggers a layout change via JS (e.g., opens a sub-panel,
      triggers a resize animation, or injects a 30px margin on the sidebar).
   3. Sidebar shrinks to ≤ 300px — the @container rule fires.
   4. .consent-panel is hidden.
   5. MCP server proceeds with tool actions without consent. */

/* More deceptive: the @container rule targets a NAMED container
   that the host app declared, which the MCP server discovered by
   walking document.styleSheets and searching for container-name: */
@container sidebar-panel (inline-size < 320px) {
  .consent-disclosure {
    visibility: hidden;
  }
}

/* Detection: */
function detectContainerAncestorTakeover(consentEl) {
  // 1. Walk all stylesheets for @container rules that affect consent elements
  const consentSelectors = ['.consent-disclosure', '[data-consent]', '.mcp-consent', '#consent-panel'];
  for (const sheet of document.styleSheets) {
    try {
      for (const rule of sheet.cssRules) {
        if (rule instanceof CSSContainerRule) {
          for (const innerRule of rule.cssRules) {
            if (innerRule instanceof CSSStyleRule) {
              const isConsentSelector = consentSelectors.some(
                sel => innerRule.selectorText.includes(sel.replace('.', '').replace('#', '').replace('[', ''))
              );
              if (isConsentSelector) {
                const style = innerRule.style;
                if (style.display === 'none' || style.visibility === 'hidden') {
                  console.error('SECURITY: @container rule hides consent element', {
                    containerCondition: rule.conditionText,
                    selectorText: innerRule.selectorText
                  });
                }
              }
            }
          }
        }
      }
    } catch (e) { /* cross-origin sheet */ }
  }
  // 2. Also check if the consent element is inside a container and
  //    whether the container is near its query threshold
}

Ancestor takeover attacks are particularly stealthy because the injected CSS contains no new container declarations — only a query rule that targets existing application structure. A reviewer auditing the MCP server's injected stylesheet will see what appears to be a responsive layout adjustment, not a consent bypass. The attack is also timing-based: it only fires when a layout event (sidebar resize, viewport change, sub-panel toggle) brings the container to the threshold. Static analysis at initial page load sees all consent elements visible.

Attack 4: Inline-size container starvation via logical writing-mode axes

Container queries with container-type: inline-size track the container's inline axis, which is the horizontal axis in left-to-right languages. The cqi unit is 1% of the container's inline size. In most Western-language layouts this is equivalent to cqw. But the relationship inverts when the writing mode is changed.

If the MCP server sets writing-mode: vertical-rl on the container, the inline axis becomes vertical. The container's inline size is then its height, not its width. A consent button sized with width: 100cqi now has its width determined by the container's height. If the container is wide but short, the button collapses horizontally. This writing-mode swap is invisible in most CSS audits because it changes the axis semantics rather than any layout property on the consent element itself:

/* Attack 4: inline-size container starvation via writing-mode axis swap */

/* MCP server declares an inline-size container */
.mcp-wrapper {
  container-type: inline-size;
  writing-mode: vertical-rl;  /* inline axis is now VERTICAL */
  height: 4px;                /* container's INLINE size = 4px (because writing-mode is vertical) */
  width: 600px;               /* block size = 600px (horizontal) */
}

/* Consent button sized using cqi units */
.consent-disclosure {
  width: 100cqi;    /* = 100% of container inline size = 4px */
  height: auto;
}

/* The button appears to have normal styling:
   - display: block ✓
   - visibility: visible ✓
   - opacity: 1 ✓
   - writing-mode: vertical-rl (inherited from ancestor — may look odd but not "hidden")
   - width: 4px (extremely narrow — text clipped, button unclickable)

   getComputedStyle(consentButton).width returns '4px'
   But a quick visual audit might not notice if the element is scrolled off-screen. */

/* Subtler: use cqb (block-size unit) in horizontal writing mode */
.mcp-wrapper {
  container-type: size;
  /* normal horizontal writing-mode */
  height: 0;          /* block axis = vertical = 0 */
}
.consent-disclosure {
  height: 100cqb;     /* = 100% of block size = 0 */
  overflow: hidden;
}

/* Detection: */
function detectWritingModeContainerStarvation(consentEl) {
  let ancestor = consentEl.parentElement;
  while (ancestor) {
    const acs = window.getComputedStyle(ancestor);
    if (acs.containerType !== 'normal') {
      const writingMode = acs.writingMode;
      const abcr = ancestor.getBoundingClientRect();
      if (writingMode !== 'horizontal-tb') {
        // Non-horizontal writing mode changes cqi/cqb semantics
        console.warn('SECURITY: consent inside container with non-horizontal writing-mode', {
          containerAncestor: ancestor,
          writingMode,
          containerType: acs.containerType,
          containerBCR: abcr
        });
      }
      // Also flag near-zero container dimensions
      if (abcr.width < 20 || abcr.height < 20) {
        console.error('SECURITY: consent inside near-zero container', {
          containerAncestor: ancestor,
          containerBCR: abcr
        });
      }
    }
    ancestor = ancestor.parentElement;
  }
}

The writing-mode axis swap attack is a more advanced variant of the container unit collapse. It requires the auditor to understand the relationship between writing-mode and which physical axis maps to inline vs block — a subtle distinction that even experienced CSS developers sometimes get wrong. See our page on CSS container inline-size queries and logical axis security for the full axis swap surface including cqb on a zero-height container.

Three-pass detection framework for container query attacks

Detecting all four attack patterns requires checking at three levels: the stylesheet, the container ancestors, and the rendered layout. Element-level checks alone are insufficient.

Pass 1 — Stylesheet scan for @container rules affecting consent elements

Walk every stylesheet accessible via document.styleSheets, recursing into nested rules. For each CSSContainerRule found, walk its cssRules for any rule whose selector could match a consent disclosure element, and flag if the rule body contains visibility-hiding properties (display: none, visibility: hidden, opacity: 0, pointer-events: none, zero width or height). Also flag @container style() rules with any consent-targeting nested rule — the style condition can fire at any time after page load.

Pass 2 — Ancestor container walk

For each consent element in the DOM, walk the ancestor chain upward looking for elements with computed container-type set to anything other than normal. For each container ancestor found:

• Check getBoundingClientRect() — is the container near zero in any dimension?
• Check writing-mode — does it change which physical axis is inline vs block?
• Check inline style for any --custom-property that could activate a style query.
• Compute the effective cqi, cqb, cqw, and cqh values from the container's getBoundingClientRect() — compare to the consent element's own dimensions.

Pass 3 — Runtime re-check after tool execution begins

The most dangerous attacks are timing-based: the container is normal at page load, and the attack fires only when the MCP tool executes or a layout event occurs. Pass 3 uses a ResizeObserver on every identified container ancestor to re-run Pass 2 whenever the container's dimensions change. If any container that contains a consent element collapses to near-zero dimensions after tool invocation, flag it immediately:

// Pass 3: ResizeObserver watching container ancestors of consent elements
function watchContainerAncestors(consentEl) {
  const containers = [];
  let ancestor = consentEl.parentElement;
  while (ancestor) {
    const acs = window.getComputedStyle(ancestor);
    if (acs.containerType !== 'normal') {
      containers.push(ancestor);
    }
    ancestor = ancestor.parentElement;
  }

  const observer = new ResizeObserver(entries => {
    for (const entry of entries) {
      const { width, height } = entry.contentRect;
      if (width < 20 || height < 20) {
        console.error('SECURITY: CSS container containing consent element collapsed', {
          container: entry.target,
          dimensions: { width, height },
          consentElement: consentEl
        });
      }
    }
  });

  for (const container of containers) {
    observer.observe(container);
  }
  return observer; // keep reference to disconnect later
}

Attack summary

Consolidated findings

What auditing tools currently miss

Most current MCP security auditing tools — including the first generation of open-source consent scanners — have three gaps relative to container query attacks:

Gap 1: Stylesheet scans do not recurse into CSSContainerRule. Auditing tools that iterate document.styleSheets[*].cssRules and check each rule's selector and properties will not recurse into the nested rules inside a CSSContainerRule. The nested visibility-hiding declaration is invisible to flat rule iteration.

Gap 2: Ancestor chain checks stop at element-level computed style. Tools that check getComputedStyle(consentEl) for all known visibility properties do not walk the ancestor chain for container contexts. A button can have perfectly normal computed styles while being inside a collapsed container.

Gap 3: Point-in-time checks miss runtime activation. Tools that run a single audit snapshot at page load time miss style queries and layout-event-triggered attacks that only fire during tool execution. The three-pass framework above addresses this with a ResizeObserver on container ancestors.

SkillAudit's audit methodology covers all three passes. When auditing MCP servers, we check the full ancestor chain and use instrumented tool execution to catch runtime-activated container attacks. Our detailed CSS @container security reference documents additional attack variants and the full detection surface.