HTML Native Consent Attacks Beyond CSS

The HTML <dialog> element provides two open methods: showModal() places the dialog in the browser's top layer with a backdrop and focus trap, while show() opens it as a normal document element with neither. An MCP server that calls dialog.show() for its consent modal has consent text present in the DOM — the static source looks fine — but the dialog renders without a backdrop and without focus trapping. Other fixed-position elements with higher z-indexes can cover it entirely.

Even with correct showModal() usage, three more attacks apply. First, the ::backdrop pseudo-element's z-index can be set higher than the dialog content, covering the consent text with an opaque overlay while leaving the submit button visible in a higher stacking context. Second, setTimeout(() => dialog.close(), 800) auto-closes the consent dialog after 800ms — less than 2% of the reading time required for a 200-word disclosure. Third, autofocus on the submit button causes the browser to focus the "I Agree" button immediately on dialog open — a keyboard user whose next keystroke is Enter submits consent before reading a word.

See the full reference page: MCP server HTML dialog element consent security.

The <details> element renders a collapsed disclosure widget by default. Its summary is visible; everything else is hidden until the user clicks to expand it. When an MCP server places consent text as the body of a <details> element — not the <summary> — the consent text is present in the DOM but not visible in the collapsed default state. A DOM auditor searching for consent text finds it; a visual user sees only the summary heading.

Three more attacks layer on top. JavaScript can call detailsElement.removeAttribute('open') 200ms after page load, re-collapsing any details element the MCP server opened at render time — the consent text flashes briefly then disappears. CSS details[open] .consent { display:none } creates an inversion: consent visible when collapsed, hidden when expanded. And the <summary> itself can be styled to look like the install button, so clicking "Install MCP Server" (the summary) expands the details while also recording the click as consent — two events from one interaction.

See the full reference page: MCP server HTML details element consent security.

The canvas API renders graphics imperatively — ctx.fillText("I authorize credential access", x, y) paints pixels, not DOM text nodes. Every standard auditing technique fails: document.body.innerText, querySelectorAll, ARIA accessibility tree, screen reader traversal. The consent text exists as a bitmap; DOM inspection returns nothing. This is the most complete DOM bypass available to an MCP server without injecting hidden elements.

On top of the basic fillText bypass, three variants extend the attack surface. fillStyle = getComputedStyle(document.body).backgroundColor draws consent text in background-matching ink — invisible to the human eye, present to a hypothetical OCR auditor only if they achieve non-zero contrast. A canvas element positioned absolutely above a real consent <div> with a higher z-index and an opaque white fill covers the consent text while leaving it in the DOM (DOM audits pass, visual rendering fails). And OffscreenCanvas draws in a memory buffer that never attaches to any visible surface — the code path executes, the drawing call fires, the consent text never reaches the screen.

See the full reference page: MCP server HTML canvas element consent security.

CSS appearance:none strips the browser's native checkbox rendering, handing complete visual control to pseudo-elements. An attacker inverts the expected behavior: :not(:checked)::before { content: "✓" } — the checkmark pseudo-element is shown when the checkbox is unchecked, and removed when checked. The user sees a green checkmark and believes consent is given; checkbox.checked === false. The consent recording logic reads the false state as implicit agreement.

type=range can be styled with CSS appearance overrides into a pixel-perfect toggle switch, with an initial value pre-set to the maximum (consent threshold). The slider starts "on" — no interaction required. type=hidden submits a server-controlled value to the backend regardless of what the visible checkbox shows — a common variant pairs a decorative visible checkbox with a hidden input named agreed that always submits 1. And type=submit on a "Continue" button inside a consent form records consent on any form submission without validating that the consent checkbox is actually checked.

See the full reference page: MCP server HTML input type consent security.

A <select size="1"> shows only the selected option in its closed state — all other options are hidden behind the dropdown interface. Consent disclosure text placed inside non-selected option elements is present in the DOM but invisible until the user clicks to open the dropdown. If the default selected option displays a neutral phrase like "Standard Access", the user proceeds without ever seeing the consent text in the hidden options.

The <optgroup label="…"> attack is more subtle: the optgroup label displays as a group header inside the open dropdown, but it is not selectable, does not appear in the submitted form data, and is invisible when the dropdown is closed. Full consent disclosures placed in optgroup labels are in the DOM, briefly visible in the expanded dropdown, and completely absent from form submissions. The change-event attack records consent on any selection — including selecting "No" — by triggering recordConsent() in the event handler without checking select.value.

See the full reference page: MCP server HTML select option consent security.

The disabled attribute on a <fieldset> propagates to every form control inside it — checkboxes, selects, and buttons all become unresponsive to user interaction. A <fieldset disabled> containing a consent checkbox renders a gray, click-proof checkbox. The user sees the consent UI and tries to check the box; nothing happens. The installation proceeds anyway because the consent recording logic does not require the checkbox to have been actively checked by the user.

The <legend> element is the fieldset's visible title, positioned at the top-left of the border. CSS properties like margin-left: -9999px or transform: translateX(-200vw) can displace the legend off-screen while leaving its text in the DOM — the classic off-screen text technique applied to a fieldset label. Auditors searching for consent text find it in the legend; layout-unaware analysis misses that the element is 9999px to the left of the viewport.

See the full reference page: MCP server HTML fieldset legend consent security.

The label element's power is its click delegation: clicking anywhere within a label activates its associated control. This delegation becomes an attack surface when the association is wrong. A label reading "I agree to credential access and terms of service" with for="newsletterCb" checks the newsletter signup checkbox on click — not the consent checkbox. The user clicked the agreement; the consent checkbox remains unchecked. DOM auditors find the consent text in the label; they do not verify that the label's for attribute resolves to the consent control.

Implicit label association (label wrapping an input directly) provides a more subtle variant: a label wrapping a hidden <input type="checkbox"> surrounded by visible "I Agree" text checks the hidden input when clicked — with no visual feedback. The visible decorative checkbox nearby is not a real form control. CSS pointer-events:none on a label disables its activation behavior entirely, passing clicks through to whatever is below in the stacking context — often an install button. And multiple labels pointing to the same non-consent input turn every ordinary interaction (clicking the username field label, clicking a step heading) into a covert consent trigger.

See the full reference page: MCP server HTML label element consent security.