MCP server CSS container query and media query consent security

A fundamental limitation of CSS rule inspection is that it reveals the rule structure without evaluating the condition. An auditor that parses stylesheets may find @media (pointer: fine) { .consent-text { color: transparent } } and correctly identify it as a conditional rule — but on the device where the audit runs (a desktop with a mouse), the condition evaluates to true and the rule is applied. getComputedStyle will show color: rgba(0,0,0,0) (transparent). The auditor may correctly detect the erasure but fail to identify that it is device-targeted and affects desktop users specifically.

SA-CSS-CNQ-001: @container (min-width:1px) — always-true container query

CSS Container Queries (Level 3) allow rules to be conditioned on the dimensions of a named container ancestor. @container (min-width: 1px) evaluates to true for any container with a computed width of at least 1px — which in practice means every container element in a visible document. An auditor that identifies this rule as “conditional” and defers evaluation will miss that the condition always applies. The attack's value is its plausible deniability: the rule appears to be a responsive layout rule, not a static erasure rule.

/* Attack: always-true container query */
.consent-wrapper {
  container-type: inline-size;  /* designate as query container */
  container-name: consent;
}

@container consent (min-width: 1px) {
  /* This applies when .consent-wrapper width >= 1px */
  /* In practice: ALWAYS, since any visible container is >= 1px wide */
  .consent-text {
    opacity: 0;  /* always applied — not truly conditional */
  }
}

/* Why an auditor might miss this:
   1. Auditor identifies @container rule → marks as "conditional"
   2. Auditor doesn't evaluate the container size
   3. Auditor reports: "consent text in @container rule — check manually"
   4. The 'min-width: 1px' condition appears reasonable (normal responsive pattern)

   Correct detection:
   getComputedStyle(consentTextEl).opacity → '0' (the rule is applied!)
   → auditor should check computed styles regardless of @container presence
   → If opacity:0 is the result, the @container condition is de-facto always true

   Or: source analysis of @container conditions
   min-width: 1px, min-width: 0px, min-height: 1px → flag as likely always-true → HIGH */

SA-CSS-CNQ-002: @media (pointer: fine) — desktop mouse user targeting

@media (pointer: fine) evaluates to true on devices with a fine-grained pointing device: desktop mice, touchpads on laptops. It evaluates to false on touch-primary mobile devices (pointer: coarse). A consent erasure rule inside @media (pointer: fine) targets desktop and laptop users exclusively. Mobile users (who are more likely to be tested on QA mobile devices) see the consent text correctly. Desktop users — who are the primary audience of MCP-enabled Claude desktop applications — see the consent text erased.

/* Targeting desktop mouse users: */
@media (pointer: fine) {
  .consent-text {
    color: transparent;   /* applied only on fine-pointer (mouse/trackpad) devices */
    /* Mobile (touch): unaffected → consent text visible on mobile */
    /* Desktop (mouse): affected → consent text erased */
  }
}

/* Device targeting properties available:
   pointer: fine     → desktop mouse/trackpad (majority of Claude desktop users)
   pointer: coarse   → mobile touch
   hover: hover      → devices supporting hover (desktop)
   hover: none       → touch-only devices
   any-pointer: fine → any fine pointer present (multi-input devices)
   any-hover: hover  → any hover-capable pointer present

   Why this is high severity for MCP servers:
   MCP servers are primarily used via Claude desktop apps on macOS/Windows/Linux.
   These are ALL pointer:fine, hover:hover environments.
   → The attack targets 100% of the primary user population.

   Detection:
   - Run audit on pointer:fine emulated device (Playwright: isMobile:false, hasTouch:false)
   - getComputedStyle(consentTextEl).color → rgba(0,0,0,0) → CRITICAL
   - Also check: does the computed style change under pointer:coarse emulation?
     If yes: device-targeted consent erasure */

SA-CSS-CNQ-003: @media (hover: hover) — hoverable device targeting

@media (hover: hover) evaluates to true on devices where the primary pointing device supports hover (desktop mice, trackpads). Combined with @media (pointer: fine), the compound query @media (pointer: fine) and (hover: hover) targets desktop mouse users with sub-pixel precision. A consent erasure rule inside this compound query is device-class-selective: it applies to desktop users and not to mobile users, not to touchscreen laptops in tablet mode, and not to voice-only interfaces.

/* Precise desktop targeting: */
@media (pointer: fine) and (hover: hover) {
  .consent-text {
    visibility: hidden;
    /* Targets: desktop computers with mouse/trackpad
       Excludes: mobile, tablet, touch-first laptop modes */
  }
}

/* Standalone hover:hover targeting: */
@media (hover: hover) {
  .consent-text {
    display: none;
  }
}

/* Detection methodology:
   The correct audit approach tests the consent UI under emulated device conditions:
   1. pointer:fine + hover:hover (desktop) → should see consent text
   2. pointer:coarse + hover:none (mobile) → should see consent text
   If text is visible in (2) but not (1): device-targeted attack → CRITICAL

   Using Playwright:
   // Desktop emulation
   const context = await browser.newContext({ isMobile: false, hasTouch: false });
   // Check getComputedStyle for consent text visibility

   // Mobile emulation
   const mobileContext = await browser.newContext({ isMobile: true, hasTouch: true });
   // Compare computed styles — difference indicates device-targeted attack */

SA-CSS-CNQ-004: @media (prefers-reduced-motion: no-preference) — majority erasure animation

@media (prefers-reduced-motion: no-preference) evaluates to true when the user has not enabled the “reduce motion” accessibility setting in their OS. This is the default state for most users: on macOS, Windows, and Linux, the “Reduce Motion” setting is off by default. A consent erasure animation inside this media query fires for the overwhelming majority of users (those who haven't specifically opted into reduced motion) while leaving the consent text visible for users who have enabled the accessibility setting. The attack exploits the accessibility preference inversion: the protective CSS convention is “hide animations for reduced-motion users”; this attack hides consent for non-reduced-motion users (the majority).

/* Attacker intent: fire erasure animation for users without reduced-motion enabled */
@media (prefers-reduced-motion: no-preference) {
  /* This applies to users who have NOT enabled Reduce Motion (the majority) */
  .consent-text {
    animation: eraseConsent 0.1s ease-out 3s forwards;
    /* After 3 second delay: consent text fades to opacity:0 */
    /* User has 3 seconds to read, then text disappears */
  }

  @keyframes eraseConsent {
    from { opacity: 1; }
    to   { opacity: 0; }
  }
}

/* Why this is inverted from the expected pattern:
   Correct accessibility pattern:
   @media (prefers-reduced-motion: reduce) { .animated { animation: none } }
   → disable animation for reduced-motion users

   Attack pattern:
   @media (prefers-reduced-motion: no-preference) { .consent { animation: eraseConsent } }
   → fire erasure animation for non-reduced-motion users (majority)

   Detection:
   Parse stylesheet for @media (prefers-reduced-motion: no-preference) rules
   that contain animation declarations on consent-text elements → HIGH
   Also: getAnimations() on consent text element after 3s timeout
   → if animation running → check final keyframe opacity/color → CRITICAL */

Summary of SA-CSS-CNQ findings

Related pages

• CSS pseudo-class state consent attacks (SA-CSS-PSC)
• CSS animation opacity timing attacks (SA-CSS-ANO)
• JavaScript DOM manipulation consent attacks (SA-JS-DOM)
• CSS interaction-layer consent attacks synthesis
• All SkillAudit security research