It's tempting to treat CSS as inherently incapable of causing security harm — no code execution, no data access APIs. This intuition is dangerously wrong, and understanding exactly why is essential for anyone accepting any form of user-controlled CSS.
1How CSS Alone Can Exfiltrate Data
The core mechanism combines two entirely ordinary, individually harmless CSS features: attribute value-matching selectors (input[value^='a'] matches an input whose value *starts with* 'a') and the fact that background-image: url(...) triggers a genuine network request the moment its rule actually matches an element. Neither feature is remotely unusual on its own — but combined adversarially, an attacker can inject a large set of rules, one per possible character (or even per possible character at each position in the value), each pointing to a distinct, attacker-controlled URL.
Because only the rule whose selector actually matches the field's real, current value fires its corresponding network request, an attacker monitoring their own server's incoming requests can reconstruct the field's value character by character, purely by observing which specific URLs were actually requested — a genuine, demonstrated data exfiltration technique using nothing but CSS.
2Beyond Static Values: Inferring Behavior In Near Real Time
The exfiltration technique isn't limited to a field's static current value — pseudo-classes that reflect dynamic state, like :valid/:invalid (reflecting whether current input satisfies HTML validation constraints), :checked, or :focus, can each be paired with a distinct network request the same way. This lets an attacker infer information about *behavior over time*, not just a snapshot value — observing exactly when a password field transitions to :valid reveals information about when specific validation criteria were satisfied, which combined with timing analysis can leak more than a naive reading of the technique might suggest.
The underlying principle generalizes broadly: any CSS feature whose matching behavior depends on user-controlled or user-modifiable state, combined with any CSS feature that triggers an observable side effect (a network request being the most common), is a potential building block for this category of attack.
3Why This Needs Its Own Dedicated Defense, Separate From XSS
The single most important practical takeaway: a site's careful, well-implemented defenses against script-based XSS — sanitizing <script> tags, stripping JavaScript event handler attributes, enforcing a strict Content Security Policy — do not automatically protect against CSS injection, because it's a genuinely different attack surface with different entry points. A user-customizable profile theme feature, an unsanitized style attribute accepted from user input, or an SVG upload containing embedded <style> content are all potential CSS injection vectors that a JavaScript-focused security review can easily overlook entirely.
Any feature accepting user-controlled CSS — even something that looks as innocuous as 'let users pick a custom accent color for their profile' — deserves the same dedicated security review and sanitization attention as any other user-controlled input, rather than being waved through on the assumption that 'it's just CSS, what's the worst that could happen'.
4Step-by-Step Breakdown
CSS Isn't As Harmless As It Looks. CSS has no obvious way to 'run code' or 'steal data' the way JavaScript does — no fetch, no eval. And yet, attacker-controlled CSS injected into a page has been demonstrated to exfiltrate form data, infer what a user has typed, and detect visited links, entirely through legitimate, otherwise-unremarkable CSS features used adversarially.
Attribute Selector Exfiltration. input[value^='a'] matches an input whose current value starts with the letter 'a' — an attacker who can inject CSS can define one selector per possible starting character, each loading a distinct background-image URL, and infer a form field's value character by character purely from which network requests actually fire.
Attribute Selector Exfiltration. How does an attacker infer a form field's actual value using only injected CSS, with no JavaScript involved?
- →CSS directly reads and transmits the DOM value to a server
- →By defining one rule per possible character using an attribute value-matching selector, each paired with a distinct background-image URL — only the rule matching the field's actual current value fires its network request, revealing the value character by character
- →This isn't actually possible with pure CSS at all
Keystroke Inference Through :valid/:invalid And Similar State Selectors. Beyond static values, dynamic pseudo-classes like :valid, :invalid, or even a carefully-constructed sequence of attribute selectors updating per keystroke, can be combined with distinct background requests to infer information about what a user is actively typing, in near real time, without ever needing JavaScript to read the input's value directly.
Real-Time State Inference. Why is combining CSS state-change pseudo-classes with a background-image URL a genuine information leak, even without directly reading the input's value?
- →It isn't actually a real leak, since no value is directly read
- →The timing and occurrence of the triggered network request itself reveals information — like exactly when a field transitions to a valid state — which can be enough to infer meaningful information about user behavior or input
- →This specific technique actually requires JavaScript to work
Why This Is A CSS Injection Problem, Not Just An XSS Problem. The critical, easy-to-miss point: these attacks work through CSS injection specifically — a site that carefully sanitizes against script injection (XSS) but allows unsanitized, attacker-controlled CSS (a user-customizable profile theme, an unsanitized <style> tag, or an SVG upload with embedded CSS) remains vulnerable to this entire category, even with otherwise excellent JavaScript-focused security practices.
CSS Injection vs XSS. Why can a site with strong protections against JavaScript-based XSS still be vulnerable to CSS injection attacks?
- →They're actually the same vulnerability, and XSS protection automatically covers this too
- →CSS injection is a distinct attack surface — a site can correctly sanitize script tags and JavaScript-executing content while still allowing unsanitized, user-controlled CSS through a different input path (a theme customizer, an unsanitized style attribute)
- →This isn't actually a meaningful real-world risk in practice
CSS Injection Understood. You now understand exactly how attacker-controlled CSS can exfiltrate form data through attribute selector matching, infer real-time user behavior through state-change pseudo-classes, and — most importantly — why CSS injection is a genuinely distinct security category requiring its own dedicated sanitization attention, separate from standard JavaScript-focused XSS defenses.
Style Via A Trusted Class, Not Untrusted Data. Styling directly from an untrusted attribute's value is an injection risk — target a fixed, trusted class instead.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1CSS Injection Defenses Should Not Come At The Cost Of Legitimate, Accessible User Customization Features
Some user-customization features (like a user-selected high-contrast theme) are genuinely valuable accessibility affordances — the goal of CSS injection defense is sanitizing and constraining untrusted input safely, not eliminating legitimate customization capability entirely.
2Overly Aggressive CSS Sanitization Can Accidentally Strip Legitimate Accessibility-Related Properties A User Genuinely Needs
A sanitization allowlist that's too restrictive might block legitimate use cases like user-controlled font-size or contrast adjustments — balance security constraints against genuinely valuable accessibility customization needs.
SEO Implications
- 1
A Successful CSS Injection Data Exfiltration Attack Carries Severe Legal, Reputational, And Regulatory Risk
Data exfiltration via any vector, including CSS injection, can trigger data breach disclosure requirements and severe reputational harm, making this a genuine business risk deserving proactive engineering attention, not just a theoretical curiosity.
- 2
Demonstrating Rigorous Security Practices, Including Less-Obvious Vectors Like CSS Injection, Supports Broader Trust And Compliance Signals
Comprehensive security posture, covering unconventional attack surfaces, contributes to the kind of trust signals increasingly relevant to enterprise customers and compliance-driven evaluation criteria.
Best Practices
Treat Any Feature Accepting User-Controlled CSS With The Same Sanitization Rigor As Any Other Untrusted User Input
This includes theme customizers, style attributes accepted from user content, and SVG uploads — all deserve dedicated review as a genuine attack surface, not an oversight left uncovered by JavaScript-focused security practices.
Prefer An Allowlist Of Specific, Safe CSS Properties And Values Over A Blocklist When Accepting User-Controlled Styling
An allowlist (permitting only explicitly vetted properties like color and font-size) is structurally safer than trying to enumerate and block every dangerous pattern, which is easy to incompletely cover.
Frequent Bugs
A security audit flags a user-customizable theme feature for potential CSS injection despite the application having strong XSS protections elsewhere.
Recognize this as a genuinely separate attack surface requiring its own sanitization — XSS defenses for script content don't automatically cover unsanitized user-controlled CSS.
An SVG upload feature is found to allow embedded <style> content that could be used for CSS injection.
Sanitize or strip <style> content (and style attributes) from user-uploaded SVG files specifically, treating them as untrusted input requiring the same scrutiny as any other user-controlled content.
Real-World Examples
Auditing A Theme Customizer Feature For CSS Injection Risk
A security team reviewing a SaaS product's user-customizable dashboard theme feature, discovering it accepted raw, unsanitized CSS that could theoretically be used for attribute-selector-based data exfiltration against other users' form inputs.
/* Vulnerable: accepts raw, unsanitized user CSS */
<style>{user.customThemeCss}</style>
/* Mitigated: sanitized against an allowlist of safe properties */