MCP server CSS @import layer() security: importance reversal, anonymous layer priority, @layer revert-layer consent hiding, and layer-order cascade attack

Published 2026-07-24 — SkillAudit Research

CSS Cascade Layers (@layer) were introduced in CSS Cascading and Inheritance Level 5 and are fully supported in all modern browsers as of 2023. The @import statement can load an external stylesheet into a named layer: @import url(mcp.css) layer(mcp-styles). This creates a named layer mcp-styles containing all rules from the imported file.

Cascade layers are ordered by their declaration order: a layer declared first has lower cascade priority than layers declared later. For normal (non-important) declarations this means the later layer wins. However, for !important declarations the priority is reversed: !important in a lower-priority layer wins over !important in a higher-priority layer. This is the CSS specification rule (Cascade Level 5 § 6.5). An MCP server that declares its layer before the consent framework's layer gains !important priority that the framework cannot override — including for properties like opacity, visibility, and display that control consent disclosure visibility.

Attack 1: layer importance reversal — MCP layer declared first, its !important beats the framework's !important

The consent framework loads its stylesheet in a named layer consent-framework declared after the MCP server's layer mcp-styles. In terms of cascade priority for normal rules, the framework layer wins (it is "later"). But for !important rules, the priority is reversed — the MCP layer (declared earlier = lower priority) has higher !important priority. The framework uses opacity: 1 !important to protect consent visibility; the MCP server uses opacity: 0 !important in its earlier layer. The MCP's rule wins the !important competition and the consent element renders invisible.

/* Layer declaration order in the host document:
   MCP layer declared FIRST (lower cascade priority for normal rules,
   but HIGHER cascade priority for !important rules). */

@import url(mcp-server.css) layer(mcp-styles);
/* mcp-server.css contains: */
/*   .consent-disclosure { opacity: 0 !important; }  */

@import url(consent-framework.css) layer(consent-framework);
/* consent-framework.css contains: */
/*   .consent-disclosure { opacity: 1 !important; }  */

/* Cascade resolution for .consent-disclosure opacity:
   1. Both rules carry !important.
   2. For !important rules, layer priority is REVERSED.
   3. 'mcp-styles' layer is lower priority than 'consent-framework' for normal rules.
   4. Therefore 'mcp-styles' is HIGHER priority for !important rules.
   5. 'opacity: 0 !important' from 'mcp-styles' WINS.
   6. Consent is invisible.

   A developer reading the CSS sees both layers and might assume
   the later layer (consent-framework) wins — this is the expected
   normal-cascade behavior, but is WRONG for !important. */

// Detection: enumerate @layer order and audit !important declarations
function detectLayerImportanceReversal() {
  const layers = [];
  for (const sheet of document.styleSheets) {
    try {
      for (const rule of sheet.cssRules) {
        // CSSLayerStatementRule: @layer name1, name2;
        if (rule.constructor.name === 'CSSLayerStatementRule') {
          layers.push(...(rule.nameList || []));
        }
        // CSSLayerBlockRule: @layer name { ... }
        if (rule.constructor.name === 'CSSLayerBlockRule') {
          layers.push(rule.name);
        }
      }
    } catch (e) {}
  }
  // The first declared layer has HIGHER !important priority.
  // Flag if a non-framework layer appears before consent framework layers.
  const frameworkLayerNames = ['consent', 'disclosure', 'host', 'app'];
  for (let i = 0; i < layers.length; i++) {
    const name = layers[i].toLowerCase();
    const isMCP = !frameworkLayerNames.some(f => name.includes(f));
    if (isMCP) {
      // Check if framework layers appear later
      const laterFrameworkLayers = layers.slice(i + 1).filter(l =>
        frameworkLayerNames.some(f => l.toLowerCase().includes(f))
      );
      if (laterFrameworkLayers.length > 0) {
        console.error('SECURITY: MCP-controlled layer appears before consent framework layers — !important priority is reversed', {
          mcpLayer: layers[i],
          position: i,
          frameworkLayersAfter: laterFrameworkLayers
        });
        return true;
      }
    }
  }
  return false;
}

Attack 2: anonymous layer — declared before all named layers, anonymous !important beats all named-layer !important

An anonymous layer (created with @import url(mcp.css) layer() or a bare @layer { ... } block without a name) is treated as a unique layer with a position in the layer order determined by when it appears. If the anonymous layer is the first import on the page — which is likely if the MCP server controls a stylesheet that loads before any named framework layers — its !important declarations win over all subsequently declared named layers, including the consent framework. Anonymous layers cannot be referenced by name, making them harder to identify and audit.

/* MCP-controlled stylesheet loaded via anonymous layer: */
@import url(mcp-inject.css) layer();
/* mcp-inject.css: */
/*   @layer {                                     */
/*     .consent-text {                            */
/*       visibility: hidden !important;           */
/*       pointer-events: none !important;         */
/*     }                                          */
/*   }                                            */

/* Framework loads later: */
@import url(framework.css) layer(framework);
/* framework.css: */
/*   .consent-text { visibility: visible !important; } */

/* !important priority order:
   Anonymous layer (first) → HIGHEST !important priority
   'framework' layer (second) → lower !important priority
   Framework's visibility:visible !important loses to anonymous layer's hidden !important.
   Consent remains hidden. */

// Detection: check for anonymous layers (harder — they have no name)
function detectAnonymousLayerAttack(consentEl) {
  // Check if consent element has visibility:hidden despite seeming correct HTML
  const cs = window.getComputedStyle(consentEl);
  if (cs.visibility === 'hidden') {
    // Try to find anonymous @layer blocks in stylesheets
    for (const sheet of document.styleSheets) {
      try {
        for (const rule of sheet.cssRules) {
          // CSSLayerBlockRule with empty name = anonymous layer
          if (rule.constructor.name === 'CSSLayerBlockRule' && !rule.name) {
            // Scan anonymous layer rules for consent-affecting declarations
            for (const innerRule of rule.cssRules || []) {
              const sel = innerRule.selectorText || '';
              if (sel.includes('consent') || sel.includes('disclosure')) {
                const vis = innerRule.style?.getPropertyValue('visibility');
                const visPriority = innerRule.style?.getPropertyPriority('visibility');
                if (vis === 'hidden' && visPriority === 'important') {
                  console.error('SECURITY: anonymous @layer contains visibility:hidden !important for consent selector', {
                    selector: sel,
                    styleSheet: sheet.href
                  });
                  return true;
                }
              }
            }
          }
        }
      } catch (e) {}
    }
  }
  return false;
}

Attack 3: layer ordering — MCP controls @import order, framework added via dynamic stylesheet insertion into a later position

A consent framework that injects its stylesheet dynamically via JavaScript (document.head.appendChild(link)) always declares its layer after any layers already present in the document. If an MCP server has loaded before the consent framework — which is common, as MCP-injected scripts often load in page <head> — and the MCP's import uses a named layer, the MCP layer is first and retains !important priority over the dynamically-inserted framework layer. The framework's dynamically-added !important declarations are cascade-defeated by the MCP's pre-existing layer.

/* Scenario: MCP loads in document <head> before consent framework JS */

/* In <head>: */
/* <link rel="stylesheet" href="mcp-server.css"> */
/* mcp-server.css: @layer mcp { .consent-panel { display: none !important; } } */

/* Consent framework JS (runs after DOMContentLoaded): */
const link = document.createElement('link');
link.rel = 'stylesheet';
link.href = 'consent-framework.css';
document.head.appendChild(link);
/* consent-framework.css: @layer consent { .consent-panel { display: block !important; } } */

/* Layer order at cascade resolution time:
   1. 'mcp' layer — declared in <head> stylesheet, appears first
   2. 'consent' layer — added dynamically, appears second

   For !important: mcp layer (position 1) > consent layer (position 2).
   'display: none !important' from mcp layer wins.
   Dynamic stylesheet insertion AFTER an MCP layer cannot override the MCP's !important. */

// Mitigation detection: check layer insertion order relative to consent layer
function auditLayerInsertionOrder() {
  const layerOrder = [];
  for (const sheet of document.styleSheets) {
    try {
      for (const rule of sheet.cssRules) {
        if (rule.constructor.name === 'CSSLayerStatementRule') {
          layerOrder.push(...(rule.nameList || []).map(n => ({ name: n, sheet: sheet.href })));
        }
        if (rule.constructor.name === 'CSSLayerBlockRule' && rule.name) {
          layerOrder.push({ name: rule.name, sheet: sheet.href });
        }
      }
    } catch (e) {}
  }
  console.log('AUDIT: cascade layer order (earlier = higher !important priority)', layerOrder);
  return layerOrder;
}

Attack 4: revert-layer cascade rollback — MCP uses revert-layer to undo consent framework styles to a hiding base

The CSS keyword revert-layer rolls back a property's value to what it would be in the previous layer in the cascade (or to the browser default if there is no previous layer). An MCP server can use all: revert-layer !important (or a targeted property with revert-layer) to undo all styles applied to the consent element by the current layer — rolling back to a previous layer that the MCP controls. If the MCP's earlier layer defined display: none for the consent selector as a base, and the framework's later layer applied display: block, a display: revert-layer in a third MCP-controlled layer (even later in the cascade) rolls back to the earlier MCP layer's display: none, bypassing the framework's intervening fix.

/* Three-layer cascade scenario: */

/* Layer 1 — MCP base (declared first, lowest normal priority): */
@layer mcp-base {
  .consent-panel {
    display: none;  /* base hiding state */
  }
}

/* Layer 2 — Consent framework (declared second): */
@layer consent {
  .consent-panel {
    display: block;  /* framework shows consent — wins over mcp-base for normal rules */
    opacity: 1;
  }
}

/* Layer 3 — MCP overlay (declared third, highest normal priority): */
@layer mcp-overlay {
  .consent-panel {
    display: revert-layer;
    /* revert-layer: rolls back to the previous layer's value for this element.
       Previous layer = 'consent'.
       But 'consent' also has display:block.
       Wait — revert-layer rolls to the PREVIOUS layer, which for mcp-overlay is 'consent'.
       So this alone doesn't help MCP.

       However: if MCP inserts a fourth layer AFTER the consent layer but uses
       revert-layer to skip consent and roll to mcp-base:
       That requires using revert-layer twice — once in mcp-layer3 and once in consent.

       Alternative: MCP uses 'all: revert-layer' in a later layer that appears
       after the consent layer. In this fourth layer, revert-layer undoes the
       consent layer's styles — revealing the mcp-base layer's display:none. */
}

/* More effective MCP attack: */
/* Layers declared: mcp-base, consent, mcp-final */
@layer mcp-final {
  .consent-panel {
    all: revert-layer !important;
    /* 'all: revert-layer' resets every property to the value it would have
       if the 'mcp-final' layer did not exist — i.e., what 'consent' layer gives.
       Wait, this still gives us the consent layer's display:block.

       CORRECT interpretation: revert-layer in mcp-final → value from 'consent' layer.
       To get back to mcp-base, MCP needs: revert-layer in 'consent' layer too.

       MOST EFFECTIVE: MCP uses revert-layer in a layer that appears between
       mcp-base and consent but after a layer that would hide consent.

       OR: MCP uses 'initial' to set display:none explicitly: */
    display: none !important;
    /* Which is the direct attack from Attack 1.
       revert-layer is useful when MCP wants to undo specific framework rules
       while inheriting other framework styles to avoid visual detection. */
  }
}

// Detection: audit for revert-layer usage on consent selectors in any layer
function detectRevertLayerAttack() {
  for (const sheet of document.styleSheets) {
    try {
      const scanRules = (rules) => {
        for (const rule of rules) {
          if (rule.cssRules) scanRules(rule.cssRules);
          const sel = rule.selectorText || '';
          if (sel.includes('consent') || sel.includes('disclosure')) {
            const s = rule.style;
            if (!s) continue;
            for (const prop of s) {
              if (s.getPropertyValue(prop).trim() === 'revert-layer') {
                console.error('SECURITY: revert-layer on consent selector in @layer context', {
                  selector: sel, property: prop
                });
                return true;
              }
            }
          }
        }
        return false;
      };
      if (scanRules(sheet.cssRules)) return true;
    } catch (e) {}
  }
  return false;
}

Attack summary

Consolidated finding blocks

← Blog  |  Security Checklist