MCP server CSS :focus-within pseudo-class security

CSS :focus-within attack surface vs. :focus-visible

Attack 1: form:focus-within hides sibling consent block during form fill

The most direct attack targets consent elements that appear after the form in the page DOM. When any field inside the form receives focus, the form enters :focus-within and a sibling combinator hides the following consent block:

/* Malicious MCP injection — consent hidden for entire form interaction window */
form:focus-within ~ .consent-disclosure {
  display: none;
}

/* Visible timeline:
   - Page load: consent visible (form has no focus)
   - User clicks first field: :focus-within → consent HIDDEN
   - User fills all fields: consent remains HIDDEN throughout
   - User tabs to submit button: submit button is INSIDE the form → still :focus-within → HIDDEN
   - User clicks submit: consent never visible during active interaction
   - After submit / redirect: consent gone from page entirely
*/

/* Variant using height collapse (maintains DOM presence for accessibility auditors) */
form:focus-within ~ .consent-section {
  max-height: 0;
  overflow: hidden;
  margin: 0;
  padding: 0;
  border: none;
}

Attack 2: :focus-within overlay covers consent during form interaction

Rather than hiding the consent element, a second variant injects an obstructing overlay positioned over it when the form has focus. The consent is technically visible in the DOM and accessibility tree — but visually covered by the overlay during the entire form interaction:

/* Malicious injection — consent covered by overlay during form interaction */
.consent-section {
  position: relative; /* establishes positioning context */
}

form:focus-within ~ .consent-section::before {
  content: '';
  position: absolute;
  inset: 0;
  background: var(--bg, #ffffff); /* matches page background */
  z-index: 100;
  pointer-events: none; /* overlay does not intercept clicks */
  /* Result: consent text is present in DOM and accessibility tree,
     but visually painted over by a background-colored rectangle */
}

/* Worse: replace with fake "already agreed" message */
form:focus-within ~ .consent-section::before {
  content: '✓ You have previously agreed to our terms';
  display: flex;
  align-items: center;
  position: absolute;
  inset: 0;
  background: var(--bg, #fff);
  color: var(--accent);
  font-size: 14px;
  padding: 16px;
  z-index: 100;
  /* Real consent text invisible; fake "already agreed" message shown */
}

Attack 3: :focus-within collapses consent container during interaction

A subtler variant collapses the consent container's height and removes it from the visual layout without using display:none — allowing it to pass auditors that check for display:none specifically:

/* Malicious injection — layout-collapse that evades display:none auditors */
.page-wrapper:focus-within .consent-sidebar {
  width: 0;
  overflow: hidden;
  flex: 0;
  min-width: 0;
  /* In a flex layout, the consent sidebar collapses to zero width */
  /* The consent IS rendered — just in a zero-width box */
  /* getComputedStyle(el).display returns 'flex' (not 'none') */
  /* Automated auditors checking display:none will PASS this */
}

/* Or target via :has() to broaden scope beyond siblings */
body:has(form:focus-within) .global-consent-banner {
  transform: translateY(-100%); /* slides up, out of view */
  transition: transform 0.2s;
}

/* The transition makes the disappearance look like a legitimate UI interaction */
/* Users may attribute the sliding banner to normal page behaviour */

Attack 4: :focus-within combined with JavaScript focus redirect

The most aggressive variant uses CSS :focus-within to show consent only when the form does NOT have focus — then uses JavaScript to immediately redirect focus into the form whenever the user tries to focus the consent element (e.g., to Tab through it for screen reading). This creates an infinite redirect that prevents any focus state where consent would be visible:

/* Malicious CSS — consent visible only when form does NOT have focus */
.consent-disclosure {
  display: block; /* visible by default */
}

form:focus-within ~ .consent-disclosure {
  display: none; /* hidden when form has focus */
}

/* Malicious JavaScript complement — redirects focus back to form
   if user somehow moves focus to the consent area */
document.querySelector('.consent-disclosure').addEventListener('focusin', (e) => {
  /* User tried to focus on consent element (e.g., via keyboard Tab) */
  /* Redirect focus back to the first form field */
  setTimeout(() => {
    document.querySelector('form input:first-child').focus();
    /* This puts form back in :focus-within state → consent hidden again */
    /* The setTimeout is necessary to allow the focus event to complete */
    /* then the redirect fires on the next tick */
  }, 0);
});

/* Combined effect: the user can never simultaneously have focus-within the form
   (needed to submit) AND see the consent disclosure. One excludes the other. */

SkillAudit findings for CSS :focus-within attacks

Detection and safe patterns

/* Runtime audit: simulate focus within form and check consent visibility */
async function auditFocusWithinConsent(form, consentEl) {
  /* Baseline: no focus anywhere */
  document.activeElement?.blur();
  await new Promise(r => requestAnimationFrame(r));
  const noFocusVisible = isConsentVisible(consentEl);

  /* Simulate form focus: focus first input */
  const firstInput = form.querySelector('input, textarea, select');
  if (firstInput) {
    firstInput.focus();
    await new Promise(r => requestAnimationFrame(r));
  }
  const formFocusVisible = isConsentVisible(consentEl);

  /* Restore */
  firstInput?.blur();
  await new Promise(r => requestAnimationFrame(r));

  if (noFocusVisible && !formFocusVisible) {
    throw new Error(
      'CONSENT_INTEGRITY_FAILURE: consent element hidden when form:focus-within is active. ' +
      'Suspected :focus-within CSS attack. Consent must remain visible during form interaction.'
    );
  }

  if (!noFocusVisible && !formFocusVisible) {
    throw new Error(
      'CONSENT_INTEGRITY_FAILURE: consent element not visible in any focus state.'
    );
  }
}

function isConsentVisible(el) {
  const s = getComputedStyle(el);
  const rect = el.getBoundingClientRect();
  return s.display !== 'none' && s.visibility !== 'hidden' &&
         parseFloat(s.opacity) > 0.1 &&
         rect.height > 0 && rect.width > 0;
}

/* Safe DOM pattern: place consent INSIDE the form as the last element.
   :focus-within then applies to the SAME ancestor (the form) as the consent —
   a :focus-within rule cannot both apply to the consent's parent AND
   hide the consent without hiding all form content. */

Related security references

• CSS :focus-visible — split presentation hiding for keyboard vs. mouse users
• CSS :autofill — consent hiding when browser auto-fills credentials
• CSS :placeholder-shown — consent hiding based on input empty state
• CSS :target — consent hiding triggered by URL fragment navigation