MCP server CSS @supports consent bypass security

Background: @supports feature detection and its security implications

CSS Feature Queries were designed as a progressive enhancement tool: write a fallback for older browsers outside the @supports block, and enhanced styles inside it for browsers that support the feature. For consent security, this mechanism creates an inversion of the intended progressive-enhancement pattern: @supports attacks degrade consent visibility in capable browsers while leaving it intact in incapable ones. Because the target population (developers who install MCP skills) uses capable browsers almost exclusively, these attacks achieve near-total coverage of the install population while appearing in the CSS as a modern enhancement pattern.

Attack 1 — @supports (display:grid) universal modern browser hiding (SA-CSS-SUP-001)

CSS Grid Layout (display:grid) is supported by 97.8% of browsers globally as of 2026 (caniuse.com). Every major browser — Chrome, Firefox, Safari, Edge — in every version released since 2017 supports it. Setting @supports (display:grid) { .consent { display: none; } } effectively applies in every installation context an MCP developer will encounter. The choice of display:grid as the test feature is deliberate: it is so widely supported that the test always passes, but it is a legitimate CSS feature check that does not look suspicious in a modern stylesheet. An auditor that skips @supports blocks entirely misses this attack entirely.

/* Attack: grid-support check hides consent in all modern browsers */
@supports (display: grid) {
  .consent-required {
    display: none;
  }
}
/* CSS grid: 97.8% global support (2026) — fires in every modern browser
   Older browsers (IE11 and below) see the consent — not the install target
   textContent: unaffected — element in DOM; getComputedStyle: display:'none'
   Static audit without @supports evaluation: PASS (rule appears conditional/dead) */

/* Detection */
function checkSupportsConsent(el) {
  // Check if any @supports rule containing display:none applies to the consent element
  const cs = getComputedStyle(el);
  if (cs.display === 'none' || cs.visibility === 'hidden' || parseFloat(cs.opacity) === 0) {
    // Identify if the hiding comes from a @supports-scoped rule
    // by checking CSS.supports() for the condition
    const gridSupported = CSS.supports('display', 'grid');
    const oklchSupported = CSS.supports('color', 'oklch(0 0 0)');
    const overflowClipSupported = CSS.supports('overflow', 'clip');
    return {
      vuln: 'SA-CSS-SUP-001',
      detail: `consent hidden; CSS.supports — grid:${gridSupported}, oklch:${oklchSupported}, clip:${overflowClipSupported}`
    };
  }
  return null;
}

Attack 2 — @supports (color:oklch()) near-white text in modern browsers (SA-CSS-SUP-002)

The oklch() color function is supported in Chrome 111+, Firefox 113+, and Safari 15.4+ — covering every browser release from the past three years. Setting consent text to oklch(98% 0 0) (near-white) on a white or near-white background makes it visually invisible while the computed color value remains a valid, non-transparent color. Unlike color:transparent (which getComputedStyle returns as rgba(0,0,0,0)), an oklch near-white color returns as an rgb value with extremely high component values — a programmatic check for color === 'transparent' passes. The attack requires an additional contrast ratio check to detect: compute the luminance of both the text color and background color and verify the contrast exceeds 4.5:1.

/* Attack: oklch near-white consent text in modern browsers */
@supports (color: oklch(0 0 0)) {
  .consent-text {
    color: oklch(98% 0 0);                  /* near-white — L=98% */
    background-color: oklch(99.5% 0 0);    /* near-white background */
    /* Luminance contrast: L98 vs L99.5 → ~1.03:1 — visually invisible */
    /* getComputedStyle returns rgb(249,249,249) vs rgb(253,253,253) — not 'transparent' */
  }
}

Attack 3 — @supports (overflow:clip) clips consent in modern browsers (SA-CSS-SUP-003)

The overflow:clip value (distinct from overflow:hidden) was added to Chrome 90+, Firefox 81+, and Safari 16+. Inside an @supports (overflow:clip) block, setting overflow:clip and max-height:2px on the consent container clips it to 2px of visible height. In older browsers (and in auditors that do not support overflow:clip), the fallback is no max-height override — consent is visible at full height. The attack therefore specifically targets the modern browser population while appearing to be a progressive enhancement of the overflow handling. The text is technically rendered but clipped to two pixels — invisible to all users.

/* Attack: overflow:clip + max-height clips consent in modern browsers */
@supports (overflow: clip) {
  .consent-container {
    overflow: clip;
    max-height: 2px;   /* clips to 2px — text exists but invisible */
    /* Fallback (browsers without overflow:clip): full height visible */
  }
}
/* Chrome 90+, Firefox 81+, Safari 16+: consent clipped to 2px
   IE, older browsers: overflow:clip unknown; full consent visible
   textContent: full string; scrollHeight >> clientHeight (detectable) */

Attack 4 — @supports selector(:has(input:checked)) hides consent after checkbox (SA-CSS-SUP-004)

The CSS :has() pseudo-class is supported in Chrome 105+, Firefox 121+, and Safari 15.4+. The @supports selector(:has(input:checked)) block applies only in browsers that support :has(). Inside this block, an MCP server sets opacity:0 on a consent element when a sibling checkbox is checked: .consent-required:has(input:checked) + .consent-text { opacity: 0; }. The consent text is fully visible before the user checks the "I have read and agree" checkbox. The moment the user checks the box — confirming their purported agreement — the consent text disappears. It is unreadable at the exact moment the commitment is made. The interaction reads: present consent → user checks box to confirm → consent text immediately hides. The commitment is now irreversible; the consent is gone.

/* Attack: :has(input:checked) hides consent at confirmation moment */
@supports selector(:has(input:checked)) {
  .consent-wrapper:has(input[type="checkbox"]:checked) .consent-text {
    opacity: 0;
    transition: opacity 0s;  /* instant — no fade that might alert the user */
  }
}
/* Flow:
   1. Page loads — consent text visible
   2. User reads consent, checks "I agree" checkbox
   3. IMMEDIATELY: consent text opacity:0 — invisible
   4. User clicks Install — has "agreed" but can no longer read what they agreed to
   5. MutationObserver on checkbox change is the reliable detection path */

/* Detection */
document.querySelectorAll('input[type="checkbox"]').forEach(cb => {
  cb.addEventListener('change', () => {
    const consentEl = document.querySelector('.consent-text');
    if (consentEl) {
      const opacity = parseFloat(getComputedStyle(consentEl).opacity);
      if (opacity < 0.5) flagTampering('SA-CSS-SUP-004');
    }
  });
});