CSS mask-image as a Consent Bypass Vector

CSS mask-image controls element visibility through the alpha channel of a composited mask layer — independently of the element's opacity, color, visibility, and display. A consent element with a fully transparent mask renders zero visible pixels while every standard accessibility and security auditor reports it as fully legible. This post explains the structural reason mask attacks evade detection, maps the four canonical attack patterns, provides a step-by-step detection algorithm, compares mask to the two closest CSS attack classes (opacity and clip-path), and covers browser support and Content Security Policy scope.

The CSS mask rendering model

Standard CSS visibility properties work by modifying the element's own rendering: opacity: 0 sets the element's alpha to zero, display: none removes it from the layout tree, visibility: hidden suppresses its paint step, color: transparent makes its text invisible. All four of these are readable directly from getComputedStyle(element) — they are properties of the element itself.

mask-image works differently. The element renders normally — full color, full opacity, full layout box — and then the browser composites a mask image over the rendered output. Wherever the mask image has alpha = 1 (fully opaque), the element's pixels are visible. Wherever the mask image has alpha = 0 (fully transparent), the element's pixels are erased from the composited output. The element itself hasn't changed; only the mask layer controls what reaches the screen.

This separation — mask alpha governs the final pixels; element properties govern the rendering inputs — is what makes mask consent attacks structurally different from every other CSS consent hiding technique. There is no change to any property the element "owns." The attack lives entirely in the mask layer.

The CSS mask shorthand decomposes into mask-image (the mask source), mask-size (tile dimensions), mask-repeat, mask-position, and mask-mode (alpha vs luminance masking). Each sub-property is a separate avenue of attack. The four patterns below exploit different combinations.

Four reasons auditors miss mask attacks

WCAG 2.1 and 2.2 do not address CSS masking. The specification's color contrast algorithm (Success Criterion 1.4.3) operates on the element's computed foreground color vs its background color — not the composited output. An auditor implementing SC 1.4.3 calls getComputedStyle on the consent element, reads color and background-color, computes the contrast ratio, and reports a pass. The mask that erases the element from the composited frame is never consulted.

This structural gap produces four concrete failure modes:

1. Color/opacity checks pass. The element's computed color is dark, its opacity is 1, and its background contrast ratio is 7:1 or higher. Every legibility check reports pass. The mask is not a color or opacity property — it is a compositing operation — and WCAG does not define a mask-image check.

2. Dimension checks pass. getBoundingClientRect() returns the element's layout box. The element occupies its normal space in the document flow. There is nothing in the layout dimensions to indicate the element is invisible. Contrast with clip-path: inset(0 0 100% 0), which also preserves layout dimensions but is at least a recognizable "clip the element to zero area" instruction that a CSS static analyzer can flag.

3. Static CSS analysis is insufficient. A static CSS parser can identify that a mask is present, but determining whether the mask produces zero coverage requires evaluating the mask image. For a gradient, this means parsing the gradient function, extracting all color stops, and computing their alpha values. For a data URL, it means base64-decoding the image and reading pixel alpha channels. For a custom property reference, it means resolving the variable chain at runtime. Static analyzers typically neither parse gradients at this depth nor decode image data from URLs.

4. The -webkit-mask prefix doubles the attack surface. Older WebKit/Blink versions and some auditing tools only check the unprefixed mask-image property. The prefixed -webkit-mask-image is functionally identical and is currently required in Safari. An auditor that only checks mask-image misses all attacks delivered via -webkit-mask-image.

/* Attack: consent invisible via fully transparent gradient mask */
.consent-required {
  /* Standard visibility properties — all auditor-correct */
  color: #1a1a1a;          /* dark text — passes contrast check */
  opacity: 1;              /* no opacity reduction — passes opacity check */
  visibility: visible;     /* not hidden — passes visibility check */
  display: block;          /* in layout — passes display check */

  /* The attack: mask erases the element from the composited output */
  mask-image: linear-gradient(transparent, transparent);
  -webkit-mask-image: linear-gradient(transparent, transparent);
}

/* Variants with equivalent zero-alpha stops */
/* mask-image: linear-gradient(rgba(0,0,0,0), rgba(0,0,0,0)); */
/* mask-image: linear-gradient(hsla(0,0%,0%,0), hsla(0,0%,100%,0)); */
/* mask-image: linear-gradient(color(srgb 0 0 0 / 0), color(srgb 1 1 1 / 0)); */

/* Attack: zero-size mask tile — zero coverage — element invisible */
.consent-text {
  mask-image: linear-gradient(#000, #000); /* opaque mask source */
  mask-size: 0px 0px;                      /* zero-dimension tile */
  mask-repeat: repeat;                      /* tiling — but tile has no size */
  -webkit-mask-image: linear-gradient(#000, #000);
  -webkit-mask-size: 0px 0px;
  -webkit-mask-repeat: repeat;
}

/* The mask-image value looks like a standard black gradient — opaque
   The attack is in mask-size: 0px 0px, a separate sub-property
   Static analysis of mask-image alone reports a solid opaque mask — "safe" */

/* Attack: 1x1 fully transparent PNG as mask — zero alpha pixels, no CSS color keywords */
.consent-required {
  /* 68-byte 1x1 fully transparent PNG as base64 */
  mask-image: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNkYPhfDwAChwGA60e6kgAAAABJRU5ErkJggg==');
  -webkit-mask-image: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNkYPhfDwAChwGA60e6kgAAAABJRU5ErkJggg==');
  mask-repeat: repeat;
  -webkit-mask-repeat: repeat;
}

/* The CSS value contains: a data URL with a PNG MIME type and base64 content
   No "transparent", rgba(), alpha, or zero keyword appears anywhere
   A CSS text scanner sees a URL reference — looks like a normal image asset
   The transparent PNG is only revealed after base64 decode + PNG alpha channel read */

/* Attack part 1: :root custom property — looks like a theme variable */
:root {
  --brand-primary: #5b21b6;
  --brand-secondary: #7c3aed;
  --consent-mask: linear-gradient(transparent, transparent); /* buried in theme vars */
  --text-sm: 13px;
  --radius-lg: 12px;
}

/* Attack part 2: consent element uses the variable */
.consent-text {
  mask-image: var(--consent-mask);
  -webkit-mask-image: var(--consent-mask);
}

/* Attack part 3 (behavioral variant): JS sets the variable at mousedown */
/* installBtn.addEventListener('mousedown', () => {
     document.documentElement.style.setProperty(
       '--consent-mask', 'linear-gradient(transparent, transparent)'
     );
   }); */
/* At page load: --consent-mask is unset (mask-image resolves to 'none' — consent visible)
   At install-click mousedown: mask becomes transparent — consent disappears
   Static audit at page load: consent visible — PASS
   Audit that does not simulate mousedown interaction: PASS  */

Detection algorithm

The four attacks above require different detection paths, but they share a common entry point: a mask-image (or -webkit-mask-image) property on a consent element or its ancestors. The detection algorithm proceeds in five steps:

Step 1: Identify consent elements. Locate elements that contain or are associated with consent text. In practice this means scanning for elements with text matching consent patterns ("I agree", "by installing", "permission", "access to", "accept terms") and for elements with ARIA attributes indicating consent role.

Step 2: Check for mask properties on consent elements and ancestors. For each consent element, call getComputedStyle(el).maskImage and getComputedStyle(el).webkitMaskImage. Do the same for every ancestor up to the document body. If the value is not "none", proceed to Step 3.

Step 3: Resolve custom properties. If the computed mask-image value contains a var() reference (some browsers may return the resolved value directly, but older Chromium versions may not), explicitly read the custom property: getComputedStyle(el).getPropertyValue('--property-name'). Repeat for any nested var() references. After resolution, proceed with the fully resolved value.

Step 4: Evaluate the resolved mask source.

For gradient values: parse the gradient function, extract all color stop alpha values. Compute the mean alpha across all stops. Flag if mean alpha ≤ 0.1.

For data URL values: extract the base64 content from the url('data:...') wrapper. Decode the base64 string to binary. Load the binary as an image (using createImageBitmap() in a headless browser context). Read all pixel alpha values via a Canvas 2D context. Flag if mean pixel alpha ≤ 0.1.

Step 5: Check mask-size for zero-dimension tiles. Regardless of the mask-image value, check getComputedStyle(el).maskSize and getComputedStyle(el).webkitMaskSize. Flag any value where both dimensions are zero or near-zero (≤ 1px).

// Simplified detection implementation
async function checkConsentMask(consentEl) {
  const props = ['maskImage', 'webkitMaskImage'];
  const sizeProp = ['maskSize', 'webkitMaskSize'];
  const style = getComputedStyle(consentEl);

  for (const prop of props) {
    const val = style[prop];
    if (!val || val === 'none') continue;

    // Step 3: resolve var() if not already resolved
    const resolved = resolveCustomProperties(consentEl, val);

    // Step 4a: gradient — parse alpha values
    if (resolved.includes('gradient')) {
      const alphas = parseGradientStopAlphas(resolved);
      if (alphas.length > 0 && alphas.every(a => a <= 0.1)) {
        return { finding: 'SA-CSS-MASK-001', severity: 'CRITICAL', value: resolved };
      }
    }

    // Step 4b: data URL — decode image, read alpha channel
    if (resolved.startsWith('url("data:image/')) {
      const meanAlpha = await decodeMaskDataUrlAlpha(resolved);
      if (meanAlpha <= 0.1) {
        return { finding: 'SA-CSS-MASK-003', severity: 'HIGH', value: 'data URL' };
      }
    }
  }

  // Step 5: mask-size zero dimensions
  for (const sp of sizeProp) {
    const sz = style[sp];
    if (sz && /^0(px|%)?\s+0(px|%)?$|^0(px|%)?$/.test(sz)) {
      return { finding: 'SA-CSS-MASK-002', severity: 'HIGH', maskSize: sz };
    }
  }

  return null; // no mask consent bypass detected
}

Comparison: mask vs opacity vs clip-path

Mask attacks sit at the intersection of two other well-known CSS consent hiding classes: opacity attacks (which also operate on the element's visual rendering independently of layout) and clip-path attacks (which remove the element from the visible frame while preserving layout dimensions). Understanding the differences matters for audit prioritization.

The mask attack is the hardest of the three to detect reliably. An auditor can detect opacity: 0 with a string match. It can detect clip-path zero-area patterns with a geometric calculation on the clip function arguments. Detecting a mask attack requires gradient alpha parsing, image decode pipelines, and custom property resolution — a significantly higher implementation bar that most WCAG-based accessibility scanners have not crossed.

Browser support matrix

To cover all modern browsers with a single rule, an MCP server author would include both mask-image and -webkit-mask-image with identical values. An auditor must check both properties to avoid missing the attack on any browser segment. The prefixed form is not deprecated — Safari still requires it for most mask sub-properties — so its presence in stylesheets is not itself suspicious.

CSP scope and limitations

Content Security Policy does not have a directive that prevents mask-image usage. The style-src directive controls which stylesheets can be loaded, but once a stylesheet is allowed, all CSS properties within it are permitted — including mask-image with any gradient or data URL value. There is no way to restrict mask-image sources at the CSP level.

For data URL masks specifically: img-src does not apply to CSS mask-image: url(data:...)) in most browsers. The img-src directive covers <img> elements and CSS background-image in some browsers but not mask-image. There is ongoing discussion in the W3C CSP spec about adding mask-image source restrictions, but no current browser implements it.

The correct defence is audit-based: run a behavioral scanner that checks mask properties on consent elements at page load and after simulating the install interaction. SkillAudit's scanner checks all four mask attack patterns — transparent gradient, zero-size tile, transparent PNG data URL, and custom property indirection — as part of its standard consent-bypass detection suite. Run a free audit →

Summary

Related posts: CSS @supports and @media as MCP consent bypass vectors · CSS clip-path consent security · CSS opacity consent security