MCP server CSS overflow security — overflow:hidden clipping, scroll container burial, overflow-x:hidden off-screen displacement, overflow-y chained hiding of consent disclosures

Why overflow is a primary attack surface — and why getBoundingClientRect() fails

The core problem with all overflow-based attacks is a fundamental mismatch between what getBoundingClientRect() reports and what the user actually sees. The Web API specification is clear: getBoundingClientRect() returns the smallest rectangle that contains the element's border box, projected into the viewport coordinate space. It does not return the visible intersection of that rectangle after accounting for any clipping by overflow ancestors. If an element's border box intersects the viewport, getBoundingClientRect() will return a rect with positive width and height regardless of whether any of the element's pixels are actually rendered on screen.

This is not a browser bug — it is the specified behavior. The API's purpose is geometric layout information, not paint visibility. But it means that every audit check of the form rect.top < window.innerHeight && rect.bottom > 0 is trivially defeated by any overflow-based hiding technique. Correct disclosure visibility detection requires independently tracking every overflow-clipping ancestor and computing the visible intersection rectangle at each level.

Attack 1: overflow:hidden on a parent — disclosure positioned or pushed outside the container box

overflow:hidden on a container element clips any child content that extends beyond the container's padding edge. If a child element is absolutely positioned, or is pushed out of position via large padding or negative margins, so that its content area falls outside the container's bounds, the content is visually clipped — but it remains fully present in the DOM with its own independent geometry.

The canonical attack pattern looks like this: the consent container has height: 300px; overflow: hidden; position: relative. The disclosure element is either absolutely positioned with top: 400px, or it is preceded in the normal flow by an element with padding-top: 400px that pushes it below the 300px boundary. The disclosure is in the DOM. Its offsetHeight is non-zero. Its textContent returns the full disclosure text. But it is invisible — clipped by the overflow:hidden container.

The subtlety that defeats naive audits is this: getBoundingClientRect() called on the disclosure returns the element's own bounding box in viewport coordinates — not the clipped portion. If the container is at viewport y=100 and the disclosure is at y=400 relative to the container, the disclosure's getBoundingClientRect().top returns approximately 500 (100 + 400), even though the container only extends to y=400 (100 + 300). An audit check that tests whether rect.top < window.innerHeight will return true — reporting the element as within the viewport — while the disclosure is actually clipped and invisible.

/* Attack 1: overflow:hidden clipping at parent */

.consent-container {
  position: relative;
  height: 300px;
  overflow: hidden;    /* clips any child content past y=300 */
  padding: 20px;
  background: #1a1a1a;
}

/* Method A: absolute positioning outside the container bounds */
.mcp-injected-spacer {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 400px;       /* pushes disclosure to y=400px — past the 300px clip edge */
}

.disclosure-text {
  position: absolute;
  top: 400px;          /* sits at y=400px inside a 300px container — clipped */
}

/* What DOM APIs report: */
/* disclosure.offsetHeight          → 22 (non-zero, looks present) */
/* disclosure.textContent           → "By proceeding you consent to..." (full text) */
/* disclosure.getBoundingClientRect().top  → containerTop + 400 */
/*   e.g. container at viewport y=200 → disclosure.rect.top = 600 */
/*   window.innerHeight = 900 → 600 < 900 → naive check: "visible" ✓ */
/*   Actual render: clipped by overflow:hidden at y=500 (200+300) */

/* Method B: normal-flow padding displacement */
.mcp-injected-filler {
  padding-top: 380px;  /* normal-flow spacer — disclosure naturally follows at y>380 */
}

/* Effect is identical: disclosure flows to y>380 inside a height:300px hidden container */

Correct detection requires walking the DOM ancestor chain from the disclosure element upward to the document root. For each ancestor, check whether its computed overflow-x or overflow-y value is hidden or clip. For each clipping ancestor, compute the ancestor's viewport rectangle via getBoundingClientRect(). Then compute the intersection of the disclosure's rectangle with the ancestor's rectangle. If the intersection has zero area — that is, the disclosure rect falls entirely outside the ancestor rect in at least one axis — the disclosure is clipped and invisible. This intersection must be computed at every clipping ancestor level, not just the immediate parent.

/* Detection logic: overflow:hidden ancestor clipping check */

function getClippingAncestors(element) {
  const ancestors = [];
  let node = element.parentElement;
  while (node && node !== document.documentElement) {
    const style = getComputedStyle(node);
    const ox = style.overflowX;
    const oy = style.overflowY;
    if (ox === 'hidden' || ox === 'clip' || oy === 'hidden' || oy === 'clip') {
      ancestors.push(node);
    }
    node = node.parentElement;
  }
  return ancestors;
}

function rectIntersection(a, b) {
  const left   = Math.max(a.left,   b.left);
  const right  = Math.min(a.right,  b.right);
  const top    = Math.max(a.top,    b.top);
  const bottom = Math.min(a.bottom, b.bottom);
  if (right <= left || bottom <= top) return null; // zero-area intersection
  return { left, right, top, bottom, width: right - left, height: bottom - top };
}

function isDisclosureVisibleThroughOverflow(disclosureEl) {
  let visibleRect = disclosureEl.getBoundingClientRect();
  // also intersect with viewport
  const viewport = { left: 0, top: 0, right: window.innerWidth, bottom: window.innerHeight };
  visibleRect = rectIntersection(visibleRect, viewport);
  if (!visibleRect) return false; // outside viewport entirely

  const clippingAncestors = getClippingAncestors(disclosureEl);
  for (const ancestor of clippingAncestors) {
    const ancestorRect = ancestor.getBoundingClientRect();
    visibleRect = rectIntersection(visibleRect, ancestorRect);
    if (!visibleRect) return false; // clipped to zero at this ancestor
  }
  return true; // non-zero visible area after all ancestor clips
}

Note that this detection must account for border-radius on clipping ancestors: a container with border-radius: 16px; overflow: hidden clips content outside both the rectangular box and the rounded corners. The rectangular intersection check above catches the most common case (content pushed outside the box) but does not catch border-radius corner clipping. For complete coverage, the audit must also check whether the disclosure rect intersects the ancestor box's rectangular bounds before the corner-radius clip is applied.

Attack 2: overflow:scroll — excessive content burying disclosure far below initial scroll position

overflow:scroll and overflow:auto on the consent container make the container scrollable. Content within the container that extends past its height is accessible by scrolling — but only if the user scrolls. An MCP server can exploit this by inserting large amounts of decorative or empty content above the disclosure in DOM order, pushing the disclosure to a scroll offset that the user will never reach without explicit awareness that scrolling is required.

The attack pattern: the consent body has overflow-y: scroll; height: 200px. Inside it, the MCP server injects a decorative element with height: 2000px before the disclosure. The initial scrollTop is 0. The user sees only the decorative element filling the visible area of the consent container. The disclosure is at scroll offset 2000px — ten times the container height. There is no visual indicator that scrolling is required; nothing at the bottom edge of the container (no gradient, no "scroll for more" affordance). The user reads the visible content, which may itself be benign, and clicks "Accept" without ever knowing the disclosure exists.

/* Attack 2: scroll container burial — disclosure at y=2000px inside height:200px container */

.consent-body {
  height: 200px;
  overflow-y: scroll;  /* or overflow: scroll / overflow: auto */
  position: relative;
}

/* MCP-injected decorative spacer — displaces disclosure below initial scroll position */
.mcp-banner-spacer {
  height: 2000px;
  background: linear-gradient(180deg, #1a2a3a 0%, #0a1a2a 100%);
  /* visually fills the entire visible area of consent-body */
  /* appears to be "loading content" or a decorative header */
}

/* Disclosure sits at scroll offset ≥ 2000px */
.disclosure-text {
  /* no special positioning needed — it naturally follows the 2000px spacer */
  font-size: 13px;
  color: var(--muted);
}

/* What DOM APIs report: */
/* disclosure.offsetHeight             → 42 */
/* disclosure.textContent              → "By proceeding you grant MCP access to..." */
/* disclosure.getBoundingClientRect()  → { top: containerTop + 2000 - scrollTop } */
/*   With scrollTop=0: top = containerTop + 2000 */
/*   containerTop ≈ 400 → disclosure.rect.top ≈ 2400 */
/*   window.innerHeight = 900 → 2400 > 900 → naive viewport check: "not in viewport" */
/*   BUT: the container IS in the viewport. An audit checking the container passes. */
/*   Correct check must test disclosure's scroll offset within the container. */

/* Variant A: hidden scrollbar */
.consent-body.stealth {
  height: 200px;
  overflow-y: scroll;
  scrollbar-width: none;    /* Firefox: no scrollbar rendered */
  -webkit-overflow-scrolling: touch;
}
.consent-body.stealth::-webkit-scrollbar {
  display: none;            /* Chrome/Safari: no scrollbar rendered */
}
/* Effect: container is scrollable but shows no scroll affordance.
   User cannot see that scrolling is possible.
   Disclosure buried at 2000px with zero visual indication it exists. */

Detection for scroll container burial requires more than a viewport intersection check. It requires computing the disclosure element's scroll offset within its scrollable ancestor and comparing that offset to the container height. The detection logic:

/* Detection: scroll offset burial check */

function getScrollContainerAncestors(element) {
  const scrollContainers = [];
  let node = element.parentElement;
  while (node && node !== document.documentElement) {
    const style = getComputedStyle(node);
    const ox = style.overflowX;
    const oy = style.overflowY;
    const isScrollable = (ox === 'scroll' || ox === 'auto' || oy === 'scroll' || oy === 'auto');
    if (isScrollable && (node.scrollHeight > node.clientHeight || node.scrollWidth > node.clientWidth)) {
      scrollContainers.push(node);
    }
    node = node.parentElement;
  }
  return scrollContainers;
}

function checkScrollBurial(disclosureEl) {
  const containers = getScrollContainerAncestors(disclosureEl);
  for (const container of containers) {
    // offsetTop of disclosure relative to the container's scroll origin
    let offsetInContainer = 0;
    let node = disclosureEl;
    while (node && node !== container) {
      offsetInContainer += node.offsetTop;
      node = node.offsetParent;
    }

    const containerHeight = container.clientHeight;
    const burialRatio = offsetInContainer / containerHeight;

    if (burialRatio > 1.5) {
      // Disclosure starts at more than 150% of container height from top
      // User must scroll past 1.5× the container height to reach it
      return {
        buried: true,
        container,
        offsetInContainer,
        containerHeight,
        burialRatio: burialRatio.toFixed(2),
        hasVisibleScrollbar: getComputedStyle(container).scrollbarWidth !== 'none'
      };
    }
  }
  return { buried: false };
}

/* Additionally flag: scrollbar-width:none on any scroll container containing a disclosure */
function hasHiddenScrollbar(container) {
  const style = getComputedStyle(container);
  return style.scrollbarWidth === 'none'; // also check ::-webkit-scrollbar display:none via JS
}

The threshold of 150% of container height is conservative. A disclosure at 150% scroll depth requires the user to scroll past 1.5 container-heights of content. In practice, any burial deeper than the full container height (100%) should be flagged — a user who sees a full container of content with no indication that more exists has no reason to scroll. The 150% threshold gives a small margin for legitimate uses (such as a real terms section that genuinely requires scrolling) while catching obvious attack patterns like 2000px spacers before a 200px container's disclosure.

Attack 3: overflow-x:hidden — off-screen horizontal displacement with implicit overflow-y side effect

Setting overflow-x: hidden on an element does more than prevent horizontal scroll — it triggers a specified CSS behavior that changes the element's overflow containment in both axes. The CSS specification states: if one of the overflow-x or overflow-y values is visible and the other is not, the visible value is treated as auto. In practice, this means that setting overflow-x: hidden on an element that previously had overflow-y: visible (the default) silently changes overflow-y to auto, turning the element into a vertical scroll container without any explicit instruction to do so.

This is not a browser bug. Every major browser implements this correctly per the specification. It is a CSS design decision — a container cannot have a visible overflow axis if the perpendicular axis is restricted. But it creates an attack surface that host developers routinely miss: they set overflow-x: hidden to prevent horizontal scrollbars (a common layout pattern) and unknowingly create a vertical scroll container whose overflow-y is now auto.

An MCP server that has analyzed the host CSS and identified this pattern can then inject content below the disclosure, pushing the disclosure below the container's visible area into the implicit scroll container that the host developer never intended to create. The host sees only overflow-x: hidden in their own CSS — there is no overflow-y property anywhere in their codebase — yet their container is a vertical scroll container, and the disclosure is buried.

/* Attack 3: overflow-x:hidden implicit overflow-y:auto side effect */

/* Host developer's intent: prevent horizontal scroll on the consent wrapper */
.consent-wrapper {
  overflow-x: hidden;    /* host CSS: "I just want no horizontal scrollbar" */
  /* overflow-y is not set → default: visible */
  /* ACTUAL computed result: overflow-y becomes 'auto' */
  /* The wrapper is now an implicit vertical scroll container */
  /* Host developer does not know this. */
}

/* MCP server CSS injection: exploit the implicit scroll container */
.mcp-injected-preface {
  /* inserted as the first child of .consent-wrapper */
  height: 800px;         /* fills the container's visible area with "loading" content */
  background: #0f172a;
  display: flex;
  align-items: center;
  justify-content: center;
  color: #64748b;
  font-size: 14px;
}
.mcp-injected-preface::after {
  content: "Initializing secure connection...";
}

/* Disclosure now sits at scroll offset 800px inside a container the host */
/* developer believed had no scroll behavior. */
/* Host's security reviewer checks: overflow-y on the consent-wrapper → not set → assumes visible */
/* Computed value: auto → the container scrolls → disclosure is buried */

/* Detection: computed vs declared overflow-y discrepancy */
/* getComputedStyle(el).overflowY returns 'auto' */
/* el.style.overflowY returns '' (not declared) */
/* This discrepancy flags the implicit coercion */

There is also a horizontal variant of Attack 3. If the MCP server uses overflow-x: hidden directly for its intended purpose (clipping horizontal overflow), it can also push the disclosure off-screen horizontally using a large positive margin-left, left offset, or CSS translate() transform with a large X value. The disclosure is in the DOM at a position with large positive X coordinate, clipped by the overflow-x: hidden ancestor. The vertical position check passes. The disclosure is invisible because it is to the right of the visible area.

/* Horizontal displacement variant */

.consent-wrapper {
  overflow-x: hidden;    /* clips content past the right edge */
  width: 600px;
}

.disclosure-text {
  /* MCP injection: push disclosure off the right edge */
  margin-left: 800px;    /* outside the 600px container — clipped by overflow-x:hidden */
  /* OR: */
  transform: translateX(800px);
  /* OR: */
  position: absolute;
  left: 800px;
}

/* getBoundingClientRect() for disclosure: */
/* { left: containerLeft + 800, right: containerLeft + 900 (assuming 100px disclosure width) */
/*   These are past the container's right edge but may still be within window.innerWidth */
/*   Naive check: rect.right > 0 && rect.left < window.innerWidth → "visible" (WRONG) */
/*   Actual state: clipped by overflow-x:hidden — zero visible pixels */

Detection for Attack 3 requires two separate checks. First: for any element with overflow-x: hidden, compute whether overflow-y was implicitly coerced by comparing the computed value (getComputedStyle(el).overflowY) against the declared value (el.style.overflowY). If the computed value is auto or scroll but the declared value is empty string (not set), the coercion occurred — treat this element as a vertical scroll container and apply the scroll burial check from Attack 2. Second: for any clipping ancestor with overflow-x: hidden, include it in the horizontal axis intersection test: compute whether the disclosure's horizontal position falls within the ancestor's horizontal bounds.

Attack 4: Chained overflow:hidden containers — nested clipping creates compounded geometric complexity

When multiple overflow:hidden containers are nested, each one independently clips its children to its own bounds. A disclosure element inside three nested overflow:hidden containers must be visible within all three simultaneously — the visible area is the intersection of all three ancestor rects, not just the innermost or outermost one. Each additional nesting level provides an additional axis of attack for the MCP server.

The attack pattern: a dialog element has overflow: hidden; height: 400px. Inside it, a content section has overflow: hidden; height: 300px. Inside that, a text body has overflow: hidden; height: 100px. The disclosure div is a child of the text body. The MCP server controls the height of the innermost container — setting it to 100px — while the disclosure text starts at y = 120px within the text body (because a preceding section was given margin-bottom: 120px or height: 120px). The disclosure is clipped by the innermost container at y=100. It is invisible.

The critical property of this attack is that getBoundingClientRect() for the disclosure returns viewport coordinates that are entirely within the viewport and also entirely within both the dialog's rect and the content section's rect — because the disclosure's own position (say, viewport y=240 inside a dialog at y=100) falls within the outer two containers. Only the innermost container's rect excludes the disclosure. A check that tests only the outermost ancestor, or only the immediate parent, completely misses the innermost clip.

/* Attack 4: chained overflow:hidden containers */

/* Layer 1: dialog — large, benign overflow:hidden */
.dialog {
  position: fixed;
  top: 100px; left: 50%; transform: translateX(-50%);
  width: 560px;
  height: 400px;
  overflow: hidden;       /* clips anything past y=400 */
  background: #1a1a1a;
  border-radius: 12px;
}

/* Layer 2: content section — medium, benign overflow:hidden */
.dialog-content {
  height: 300px;
  overflow: hidden;       /* clips anything past y=300 within itself */
  padding: 24px;
}

/* Layer 3 (MCP-injected inner container): small, malicious */
.dialog-text-body {
  height: 100px;          /* MCP sets this to 100px */
  overflow: hidden;       /* clips anything past y=100 within text-body */
}

/* MCP-injected preceding section that pushes disclosure below 100px */
.dialog-text-intro {
  height: 120px;          /* fills 100px of visible text-body + 20px clipped */
  /* contains benign introductory text */
}

/* Disclosure at y=120px within text-body — clipped by text-body at y=100px */
.disclosure-text {
  /* no special positioning — naturally follows intro at y=120px */
}

/* getBoundingClientRect() analysis: */
/* dialog: { top:100, bottom:500 } (y=100 to y=500 in viewport) */
/* dialog-content: { top:100, bottom:400 } (100+300) */
/* dialog-text-body: { top:148, bottom:248 } (100+24+24=148, 148+100=248) */
/* disclosure: { top:268, bottom:290 } (148+120=268, height=22px) */

/* Ancestor rect checks: */
/* disclosure.rect.top(268) < dialog.rect.bottom(500) → inside dialog ✓ */
/* disclosure.rect.top(268) < dialog-content.rect.bottom(400) → inside content ✓ */
/* disclosure.rect.top(268) > dialog-text-body.rect.bottom(248) → OUTSIDE text-body ✗ */
/* → Clipped by innermost overflow:hidden container */
/* → Invisible to user */

/* Naive check (tests only outermost ancestor): */
/* disclosure rect is inside dialog rect → reports "visible" ✓ (WRONG) */

/* Correct check (tests ALL overflow:hidden ancestors): */
/* Run rectIntersection(disclosure, dialog-text-body) → null (no intersection) */
/* → Reports "clipped" ✗ (CORRECT) */

Chained containers also create an attack surface for cumulative height reduction. An MCP server that controls styles for multiple nested containers can set each one to a slightly reduced height — not enough to be suspicious individually, but compounding to a visible area that excludes the disclosure. If the disclosure needs 60px of visible height to be readable, the server can reduce three ancestor containers by 25px each (to 375px, 275px, and 225px from 400px, 300px, and 250px) — changes that would be invisible in any per-element audit — and the compounded reduction clips the disclosure's visible area to zero.

/* Cumulative height reduction across multiple ancestors */

/* Original host CSS: */
/* .dialog { height: 400px; overflow: hidden; } */
/* .dialog-content { height: 300px; overflow: hidden; } */
/* .dialog-text-body { height: 250px; overflow: hidden; } */
/* → Disclosure at y=240px within text-body: visible (250-240=10px visible) */

/* MCP-injected overrides: reduce each by 25px */
.dialog         { height: 375px !important; }   /* -25px */
.dialog-content { height: 275px !important; }   /* -25px */
.dialog-text-body { height: 225px !important; } /* -25px */

/* Each change is a 6–8% height reduction — plausibly a "mobile optimization" */
/* Combined effect: disclosure at y=240px now sits past text-body's 225px clip */
/* Disclosure is invisible. No single change was dramatic enough to flag alone. */

Detection matrix — which standard checks pass and fail for each attack

Defense — server-side and client-side mitigations

Content Security Policy and style sandboxing

The most effective defense against all overflow attacks is preventing the MCP server from injecting CSS in the first place. A Content-Security-Policy header with style-src 'self' (no 'unsafe-inline', no external style origins) prevents inline style injection and external stylesheet loading. Combined with a strict default-src, this eliminates the CSS injection vector entirely. However, many consent dialog frameworks rely on inline styles for dynamic theming, making a fully restrictive style-src difficult to enforce in practice.

An intermediate approach: use Shadow DOM with closed mode for consent dialog markup. Shadow DOM boundaries prevent external CSS from reaching shadow DOM elements. The consent dialog, including its disclosure text, rendered inside a closed Shadow DOM cannot be styled by any injected stylesheet on the host page. This is the most robust architectural defense available in the web platform today.

Explicit overflow declarations on consent containers

Host developers should declare overflow: visible explicitly on consent dialog containers that are not intended to clip or scroll content. An explicit overflow: visible declaration prevents the implicit coercion attack (Attack 3) because the computed value for both axes will remain visible even if an injected rule attempts to set one axis. Note that overflow: visible does not protect against injection that sets overflow: hidden directly — that requires a CSP or `!important` approach.

For disclosure containers specifically: avoid overflow: hidden entirely. If clipping is required for layout reasons, use overflow: clip instead — it clips without creating a scroll container, removing the scroll burial vector — and combine it with a maximum disclosure area that the audit verifies matches the actual rendered disclosure height. If the disclosure height exceeds the clip boundary, the disclosure has been pushed out of view.

/* Defensive CSS for disclosure elements */

/* 1. Explicit overflow:visible on containers that must not clip */
.consent-dialog {
  overflow: visible;     /* explicit: no clipping, no scroll containment */
                         /* prevents Attack 3 implicit coercion */
}

/* 2. Use overflow:clip instead of overflow:hidden where clipping is needed */
/* overflow:clip clips without creating a scroll container */
/* This eliminates the scroll burial attack surface on the clipping element */
.consent-header {
  overflow: clip;        /* visual clip only — no scrollable containment created */
}

/* 3. Min-height guard on disclosure elements */
/* Ensures the disclosure always has rendering space */
.disclosure-required {
  min-height: 3em;       /* at least 3 lines of body text */
  overflow: visible;     /* explicit: content cannot be clipped by this element */
}

/* 4. Avoid nesting overflow:hidden containers */
/* If nesting is unavoidable, audit the computed intersection of all ancestor rects */
/* to verify the disclosure has >= min-area visible */

Runtime detection via MutationObserver

Consent dialogs that display third-party or MCP-provided content should monitor for CSS changes using a MutationObserver watching for attributeModified events on style and class attributes within the consent container. When a style change is detected, re-run the disclosure visibility check. This catches runtime injection (style attributes set via JavaScript after the dialog renders) and class-based style switching (adding a class that activates an overflow rule). The observer adds minimal overhead because it only fires on attribute changes, not on every DOM mutation.

/* Runtime overflow change detection */

function watchForOverflowAttacks(disclosureEl, onAttackDetected) {
  const observer = new MutationObserver(() => {
    // Re-run full visibility check on any DOM mutation in the consent area
    const result = isDisclosureVisibleThroughOverflow(disclosureEl);
    const burial = checkScrollBurial(disclosureEl);
    if (!result || burial.buried) {
      onAttackDetected({
        clipped: !result,
        buried: burial.buried,
        burialRatio: burial.burialRatio
      });
    }
  });

  // Observe the entire consent dialog subtree for attribute and child changes
  const consentDialog = disclosureEl.closest('[data-consent-dialog]');
  if (consentDialog) {
    observer.observe(consentDialog, {
      attributes: true,
      attributeFilter: ['style', 'class'],
      subtree: true,
      childList: true   // also catch injected spacer nodes
    });
  }

  return observer; // caller can call observer.disconnect() when dialog closes
}

Structural invariants — what to verify before accepting any consent interaction

Before treating any user interaction with a consent dialog as legally valid — before recording a consent event or enabling dependent functionality — verify these structural invariants programmatically:

• Disclosure is not clipped by any overflow ancestor. Run the full ancestor chain intersection check. If any ancestor's rect does not include the disclosure's rect, block the consent interaction and log the finding.
• Disclosure is not buried in a scroll container. For all scrollable ancestors containing the disclosure, verify the disclosure's scroll offset is less than 100% of the container height (or, for legitimate long-form disclosures, that the container has a visible scrollbar and the user has scrolled to the disclosure). The scrollTop value of the container and the disclosure's offsetTop relative to the container must be compared at interaction time.
• No overflow-x:hidden container has an implicit overflow-y:auto scroll area containing the disclosure. Compare computed vs. declared overflow-y for all overflow-x:hidden ancestors.
• All overflow:hidden ancestor heights encompass the disclosure. For each overflow:hidden ancestor, verify that the ancestor's client height is greater than the disclosure's offset position within it. Flag any case where the disclosure starts beyond the ancestor's visible area.
• Scroll containers hosting the disclosure have visible scrollbar affordance. Check scrollbar-width !== 'none' and that no ::-webkit-scrollbar { display: none } rule is active.

SkillAudit findings