What is CSS? Mastering styles and security

User trust is visual. Users can only trust what they see. It’s the browser that delivers this promise visually. It’s CSS that delivers this visual promise. CSS is about more than just styling to make the pages look good and make your brand stand out.

CSS delivers UI: what users can see and what not. If you don’t see a warning popup, why would you worry? When attackers control what renders in the browsers, they’re in control of user trust. They can mislead them by injecting malicious CSS. That’s why CSS is also a hidden attack surface.

In March 2025, 150,000 websites found out the hard way. Visitors expecting legitimate sites, got Chinese gambling platforms instead. How was it done? Attackers injected malicious JavaScript and used CSS overlays to replace real pages.

TL;DR · For the reader in a hurry

CSS can't execute code but can manipulate UI
CSS enables fraud in the browser
Main attack vectors: visibility manipulation, layout attacks, external resource loading
Critical areas: login, payment, consent flows
Prevent with CSP style-src, avoid unsafe-inline, use SRI, block framing.
Detect monitoring critical pages for suspicious CSS/DOM changes and CSP violations.
Defend shifting final intent checks to the server

HTML, CSS and JavaScript: who does what?

CSS, short for Cascading Style Sheets, defines the look and feel of your digital brand. It controls the visual layer: the styles for borders, alignment, colors, fonts, spacing, size and many more style features.

It works with HTML, which gives the page its structure, and with JavaScript which runs the behavior and logic: handling clicks, showing error messages, sending or fetching data from a server. For example, HTML defines <form>, <button> or <input>, CSS picks colors, layouts and the font and JavaScript adds dynamic properties and the validation or API of the request.

HTML = content, CSS = presentation, JS = behavior.
HTML+CSS+JS = styled, dynamic web app

Here’s why security people should pay attention: HTML, JavaScript and CSS run in the browser and share the same origin and trust boundaries. The Document Object Model (DOM) is key here. When a page loads, the browser parses HTML into the DOM tree and CSS into the CSS Object Model (CSSOM). The result is the Render Tree that contains only the visible and styled elements.

JavaScript is designed to read and manipulate the DOM: it can add, change, remove and hide elements at runtime.

Everything that can change the DOM, like injected HTML or JavaScript, can change the UI and what gets displayed on the screen of the user. That creates opportunity and risk. That’s why CSS security should start with preventing DOM-manipulation: XSS prevention, CSP, CSRF and supply chain security.

From visual design to attack surface

Unlike JavaScript, CSS cannot execute code in modern browsers, but it can instruct the browser to load additional resources such as fonts, images or icons, from external servers. For example, CSS url() values in background-image or @font-face can tell the browser to get those resources from external servers.

Every stylesheet is a potential channel through which external resources are requested by the browser. If your site has been compromised by for example XSS or a compromised CDN attackers can exploit this. Therefore this attack vector should be blocked and be part of the overall client-side security posture.

Even without running code, CSS calls the shots on what gets displayed and what remains hidden with display:none; or visibility:hidden;. It can also reposition content off-screen, so users don’t even see certain options or buttons. It can move and restyle buttons and forms, hide or visually downplay warnings and consent banners or it could even add layers that change how users interact with the page.

Users act on visual cues; they can’t click buttons or read warnings they can’t see. This gives attackers many manipulation options.

If attackers can change what stylesheets are loaded or which images, fonts or icons they reference, they can influence what users see.

Research has demonstrated that CSS attribute selectors combined with background-image requests can exfiltrate data in controlled scenarios. This is primarily a theoretical concern. The more immediate CSS security risk is visual deception: using CSS to hide security warnings, reposition UI elements, or overlay fake content that tricks users into unsafe actions.

That’s how CSS becomes part of your CSS attack surface and your broader client-side attack surface and why it should be included in your risk management and assessment. After an injection vulnerability, like cross site scripting, malicious actors can weaponize CSS. In the browser, CSS is passive and cannot run code. But it can be used for visual manipulation and that is far from harmless.

How CSS nudges users to trust you

Trust follows expectations.

Users tend to trust what they see if they understand it quickly and the interface behaves as they expect. If the UI looks familiar and the flow is clear and simple, people will usually trust the process.

That makes the visual hierarchy a UX design concern. But it becomes a security concern when attackers manipulate the design. For example, you design your “Pay now” button to stand out with clear error messages to make them obvious and readable, not hard to find or easy to miss.

The opposite is obvious. If your layout is confusing and leads to misclicks or to irreversible actions without warning, trust goes down. Decent CSS and thoughtful UI design should avoid confusing layout and reduce misclicks. It should provide unambiguous feedback and give clear visual cues about what’s happening and what’s expected of users.

blueprint CSS-perception-trust (honest vs dark patterns)

Secure-by-design UX uses CSS to support and help customers to confidently find their way in your applications. If users are confused and don’t understand what is happening or why, your security controls don’t land. Users lose trust and you lose customers.

Unfortunately, guidance and manipulation can overlap. The design patterns you use to guide people, can also steer them in the wrong direction. CSS tools that support users can be abused as dark patterns: visually pushing them towards one choice while hiding safer alternatives.

Users trust familiar patterns and attackers exploit that: inject some CSS, reposition a pay button, hide a warning and overlay a fake payment form. Clear and trustworthy design alone isn't enough if someone can mess with what a user sees.

How CSS Works: CSS Syntax and Basics

To understand CSS security, keep one key idea in the back of your mind: CSS happens in the browser. It’s parsed into the CSSOM and combined with the DOM. The output is rendered as pixels on the screen. For CSS security you need to understand where CSS comes from and what it displays. Understand the mechanics helps to assess the risks and implement appropriate CSP.

What are CSS rules, selectors, properties and values?

CSS defines the rules that the browser applies to HTML elements. A CSS rule has two parts:

a selector that tells the browser which elements to target;

a declaration block with a property and value pairs that tells the browser how to style them.

In this example, buttons (a class in CSS) will have a padding (space between content and border) of 10 pixels and appear in white on a blue background.

The browser reads this as follows:

Selector (.button) - tells the browser WHAT to style
Declaration block ({ ... }) - contains all the styling instructions
Declarations (color: white;) - individual property-value pairs
Property (color) - what aspect to style
Value (white) - what to set it to

Multiple rules can target the same element, which adds to the complexity of CSS. The browser goes through a multi-step process to control the final "computed style" for every property on every element.

Despite this complexity, it happens instantly for thousands of elements, creating the visual web we see. The browser is doing incredible work behind the scenes. And that is the beauty of CSS.

But there is also a very relevant security and risk perspective when styles are applied on critical elements like warnings, login buttons, consent banners, payment buttons and so on.

Where to find CSS?

There are three places from where CSS can be applied to HTML documents.

Inline CSS applies styles directly within an HTML element using the styleattribute: <div style="color: red;">. It comes in handy if you only need to make minor style changes to a page. If an attacker uses XSS to inject HTML, they could also hide warnings or create fake UI elements by injecting inline styles. A CSP can block inline styles, but only if your own code doesn’t use them in the first place.

Internal CSS uses a <style> block in the <head> of the HTML file, a straightforward method for standalone pages with unique styles.

For complex and larger websites external CSS is more efficient because it links a separate .css file to an HTML file. External CSS ensures consistency across pages and makes maintenance easier. But if you load styles from compromised CDNs, external CSS could introduce supply chain risks. To ensure files haven't been tampered with, use Subresource Integrity (SRI) for third-party CSS, and implement a strict CSP style-src directive that only allows trusted sources.

Moving styles to external stylesheets lets you set style-src 'self' in your CSP, which blocks attacker-injected styles even if XSS vulnerabilities exist.

How CSS is applied: hierarchy and cascade

Because stylesheets come from many places, order matters. C in CSS is for "cascade": styles flow down to decide which rule wins when multiple rules apply. The browser resolves conflict with a few simple priority principles.

Origin & Importance: author styles with !important can override user styles and browser defaults

Specificity: the more specific selector wins (ID > class > element)

Source order : last rule wins

Inheritance : some properties (font and txt related) inherit from parents if not explicitly set

Quick warning: heavy use of inline styles and !important makes your CSS messy and harder to lock down with Content Security Policy later. The cascade dictates what beats what. But, a bit like rock-paper-scissors, it’s not always that easy to predict what rule wins. Especially if multiple rules match the same element or if specificity is equal. The browser picks a winner anyway.

That’s when source order kicks in, and last rule wins according to the cascade principle.

In this example: header will be black because style2.css was loaded later.

Complex stylesheets deserve attention in your security reviews, precisely because their behavior is hard to predict. If it is not clear which rule will win, there is no way to know for sure how a warning or button will appear to the user.

Understanding the CSS box model and spacing to prevent UI manipulation

CSS treats every HTML element on the page as a box, a bit like sticky notes on a board you can rearrange or stack. The CSS box model tells the browser the size and spacing of the boxes. Understanding how sizing and spacing affects element positioning is crucial for UI and security.

These are the building blocks of the model:

Content: space with text and images

Padding: space separating the content from the border

Border: line around padding (and content)

Margin: space between elements

These properties define the visual appeal and the element visibility. The size of a button and its padding affect how easy they are to click. Pack in too many small buttons with tight padding and minimal margins and misclicks become more likely, especially on mobile. Smart design helps users to see what belongs together and where to click.

Here’s the thing for security: the box model controls what people see and where they can click. From a security and risk perspective, that’s a vulnerability. Attackers can change visibility and spacing and in doing so move or hide elements.

On the one hand, overlapping boxes or aggressive use of position: absolute and z-index are useful for a modal dialogue box or a cookie banner. On the other hand, they’re problematic when used to hide warnings or to push safer options out of view.

How users are tricked in clickjacking attacks

Here’s how that works. An invisible layer is stacked on top of your content with z-index: 9999; opacity: 0. Users see your legitimate content, ‘confirm purchase’, but while they think they click your button, they’re actually clicking a hidden fraudulent transfer on the transparent layer on top.

Also, negative margins can push elements off-screen. A security warning can be pushed out of the visible area using .security-warning { margin-top: -9999px; }.

Yet other tricks to manipulate what users see:

display: none removes content
visibility: hidden hides content and preserves its space
overflow: hidden clips content that may contain warnings
overflow: visible extends content outside of its container overlaying other elements.

To prevent UI manipulation of critical flows such as login, consent, or payment, check the sizing of elements in the DOM and whether anything is stacked on top or pushed out of sight.

CSS Flexbox and Grid: modern layout techniques

Flexbox and Grid are layout models that use the box model. But instead of juggling with content, padding, border, and margin manually, they provide a more structured way to arrange elements and create flexible, responsive layouts.

CSS Flexbox puts elements in one dimension: in rows, horizontally, or in columns, vertically. It also controls how they behave across various screen sizes. Developers love it for navigation bars or toolbars because it eliminates the wrestling with floats or absolute positioning.

Now, to create a two-dimensional layout, with both rows and columns simultaneously, there’s CSS Grid. It’s ideal for dashboards and multicolumn layouts with control over both axes.

Here’s the thing: Flexbox and Grid can mess with your UI without touching the HTML.

For example, the Flexbox order property reorders what users see in spite of the DOM/tab order. The result is a mismatch between the DOM order and the visual order. When .security-warning { order: 999; } is injected, the warning you placed at the top of the page, is shoved to the bottom of the screen, buried way below the confirm button.

Users see the “confirm” button first while the warning hidden is below the fold. The DOM still lists the warning first, but Flexbox pushed it where users won’t notice it. Grid does something similar with overlapping: stack elements on top of each other and hide whatever is underneath, same idea as z-index attacks.

A third-party widget like a chat bubble or analytics tracker in a Flexbox or Grid section can shifts things around on a critical page. Important stuff gets buried, warnings drop off-screen, “Cancel” or “Reject” buttons shrink and get harder to find and so on.

Attackers can rearrange your UI with CSS alone. When you're reviewing security flows, it’s a good idea to check if what users see matches what you meant. Make sure warnings aren’t hidden somewhere or pushed where nobody looks.

CSS attack vectors: how it’s done

CSS is powerful, but not just to make your pages look good. Its power can be weaponized if attackers gain control of your style sheets. Visual manipulation enables fraud and fake overlays enable phishing.

Understanding attack patterns helps you put up your defenses. Time to look at what attackers can do with CSS and how they turn your stylesheets against you.

CSS entry points: XSS, CDNs, supply chain, and widgets

In most cases, attackers need an entry point first. Here’s how they get malicious CSS onto your page:

XSS vulnerability - Inject <style> tags or inline styles

Compromised CDN - Malicious CSS served from trusted source

Supply chain attack - Compromised npm package, theme, or plugin

Third-party widgets - Chat, analytics, A/B testing tools with layout control

These attacks target the user’s browser in different ways.

XSS and third-party widgets inject malicious CSS directly into the page while it’s running in the user’s browser.

CDN and supply chain attacks poison the CSS at the source. CDN attacks swap your CSS with malicious versions on the server. Supply chain attacks sneak malicious CSS into your codebase during the build via compromised npm package or themes.

UI deception in framing-based attacks

Some UI attacks, like framing-based clickjacking, don’t need to change your CSS at all. Instead, the attacker lures the user to their own page. They embed your site in an iframe and visually disguise what the user is clicking (UI redressing). This only works if your site can be embedded in iframes, meaning no CSP frame-ancestors restriction and no X-Frame-Options header.

But the framing risk can be exploited far beyond the classic one hidden button click. In December, security researcher Lyra Rebane shared a proof of concept that shows how. Instead of relying on classic overlays, it cleverly makes SVG filters and CSS rendering work together in a totally new way to create an interactive and multi-step clickjacking attack. The implications are serious: if embedded iframes are allowed, such an attack can leak cross-origin data as was demonstrated with Google Doc content. Bottom line: if your pages can be framed, assume attackers spotted them already.

Learn more here: https://lyra.horse/blog/2025/12/svg-clickjacking/ and https://www.theregister.com/2025/12/05/css_svg_clickjacking/

How CSS enables fraud

Once attackers control your CSS or frame your site, they use styling to control what users see. They can hide or move content and use overlays to change your UI. This is how CSS can be used to amplify deception into fraud.

CSS Attack Vectors according to risk levels

Critical Risk: immediate harm

Defend against these first: they cause immediate damage and attackers target them.

These attacks directly harm users and lead to fraud or irreversible damage. They hide warnings or trick users through visual deception in security-critical moments: login, payment, consent, and destructive actions. This includes both phishing overlays on your own page when your CSS is compromised, and traditional clickjacking if your site can be framed.

The impact can be huge. In March 2025, more than 150,000 sites were hit by a full-page hijack linking to Chinese gambling sites. The attackers injected and obfuscated JavaScript first. Then CSS acted as the amplifier, relying on an iframe to create a full-screen overlay that covered the legitimate content.

|------------|-------------|--------------|----------------|--------|

High Risk: serious security degradation

These attacks don’t always cause direct fraud, but they degrade your security controls. That’s why they need your attention next. They manipulate visual hierarchy to make safe choices harder to find or less obvious for users.

|------------|-------------|--------------|----------------|--------|

Medium Risk: lower priority

These patterns are highly constrained and hard to exploit at scale. Worth monitoring in high security contexts, but they're lower priority than active visual manipulation threats.

|------------|-------------|--------------|----------------|--------|

Focus your defenses on critical and high-risk scenarios first. This where attackers get the most value with the least effort.

Making CSS safer- Secure CSS practices: Prevent – detect – defend

CSS cannot be weaponized on its own. Attackers need an entry point first. Once that foothold exists, CSS becomes an amplifier. CSS security requires layered defense with attention focused on the scenarios that give attackers the most leverage for the least effort — especially login, consent, and payment flows.

A practical approach prevents malicious styles from loading in the browser, detects visual manipulation and defends users and systems to limit impact.

Prevent: Block attacks at the source

To prevent CSS attacks, block them at the door. If you stop inline injection and untrusted styles from loading in the browser, attackers can’t manipulate your UI

These measures will make CSS abuse much harder.

Control where styles can load from with Content Security Policy (CSP)

Use style-src 'self' to allow only styles from your domain. Of course, you’ll want to avoid style-src 'unsafe-inline' as much as possible because this control precisely enables injected styles. In case you need inline styles anyway, it makes sense to use nonces or hashes.

Don’t let fear of breaking things stop you. You can test your CSP safely before rollout with CSP Report-Only.

CSP reports show you what would break. They list inline styles and external sources that will be blocked as well as third-party dependencies you might have forgotten about. Fix those and then enforce the policy.

Pin third-party CSS with Subresource Integrity (SRI)

To prevent tampered files from loading, add SRI (integrity + crossorigin) for CDN-hosted stylesheets.

example

integrity="sha384-..." crossorigin="anonymous">

This works best for stable, versioned assets because every time the CDN updates this file, the hash changes. As a result, your SRI check will fail, and the browser will block it. That means you’ll have to manually update the integrity hash. For critical CSS that often changes, it’s better to host it yourself.

Block iframe embedding with anti-framing headers

Another big headache is classic clickjacking attacks that embed your site in an invisible iframe on a fraudulent page. Content-Security-Policy: frame-ancestors 'none' and X-Frame-Options: DENY stop attackers from embedding or overlaying fake UI elements; and consequently, from tricking users into clicking buttons they’re not even aware of.

XSS prevention = CSS security

Inline styles are a security risk. The way you prevent Cross-Site Scripting (XSS) defines your CSS security.

Most CSS abuse depends on an injection path (often XSS). If you prevent XSS, the attack won’t be able to inject <style> blocks or inline style="" attributes.

Detect: Monitor critical UI for abuse

Prevention alone isn’t enough. But you can’t fix what you can’t see. If an attack slips through anyway, detection better catches it early. So ask yourself where UI manipulation would impact security most and what red flags you should look for.

CSS tampering most likely shows up on critical UI. It a good idea to set up automated alerts for Login, checkout and payment and privacy and consent pages.

What to look for?

Now that you’ve determined where to look, watch for unknown stylesheets that appear out of nowhere and check for red flags and suspicious patterns:

extreme z-index point to overlay attacks: z-index: 9999
huge negative margins to hide content off screen: margin: -9999px
hidden security messages display: none and visibility: hidden on warnings, consent banners, or error messages
Visual reordening to bury critical information under the fold with Flexbox order: 999
Tiny font size or low contrast for limiting visibility on “Cancel/Reject” buttons font-size: 4px

How to automate detection?

Manual security checks may work for limited, smaller projects; use DevTools for red flags on your login, payment, and consent pages. Before production, test on mobile because it’s easier for attackers to hide content on a small screen.

For large and complex builds manual checks don’t scale. Build automatic detection into your security monitoring system instead:

Runtime security monitoring: c/side.dev detects DOM and CSS manipulation continuously in real-time and sends an alert when critical elements are tampered with (link)
CSP violation reports: add report-uri to your CSP so browsers report policy violations automatically. Also, run aCSP validator on every build to catch misconfigurations
Synthetic monitoring on key pages: visual regression tools catch unexpected UI changes by comparing screenshots. If a payment button shrinks or a warning disappears, you'll know before users do.
Inline styles scanners: configure your CI/CD pipeline to scan for inline styles on critical pages and block commits before they hit production.

Defend: limit damage and protect users

When prevention and detection fail, defense slows down the attack and limits the damage.

Minutes count. Apply pressure right away: isolate the problem and disable all non-critical third-party elements on critical pages. If you need to, roll back to the last known good build. Next, lock down CSP: trusted sources only; block everything you don’t control. It’s better to sacrifice features than to leave attackers free to score on your login or payment and consent pages.

Then let the server do the work. Even if CSS hides a warning or reorders the flow, your backend Cross-Site Request Forgery (CSRF) protections and step-up checks ensure the server only executes actions the user explicitly initiated.

Next, let the server do the work. Users act on what they see, but your backend shouldn’t just trust the user input. It could require extra proof of intent, re-authentication or MFA for sensitive actions. Before the final commit, have your backend send a confirmation (“You’re about to send €X to accountY”) and require out-of-band approval via app or email. Adding undo-windows for destructive steps is also good defense.

CSS can fool users, but it can’t mess with server-side validation.

Vibe coding risks for CSS security

Using a keyboard these days, means using AI coding tools. They rush web development and spit out CSS styles in seconds. But there’s a trade-off: if teams accept generated CSS without security review, they also risk speeding up their attack surface as well.

Using inline styles brings the risk of CSP bypass; uncontrolled links to external CDN without integrity checks create supply chain vulnerabilities.

What’s the problem with vibe coding?

In a perfect world, AI coding tools produce smooth UI and fun animations completely risk free. In the real world, problems go unnoticed until they don’t. And then, when something breaks, you look under the hood and find chaos.

That chaos can take many forms. You might discover inline styles that break CSP enforcement or fonts and themes pulled from unverified, random CDNs. And if you look closer, perhaps you’ll find also z-index: 999999. This is not an innocent bug fix: it creates opportunities for full screen overlays that replace your content.

Some red flags that should alarm you:

style="display: none" scattered throughout (inline styles complicate CSP and review)
Third-party CSS links without Subresource Integrity (SRI)
z-index: 999999 enables full-screen overlays
Complex Flexbox/Grid layouts nobody can explain
External icon and font CDNs loaded by default

If your priority is secure-by-design, it should be reflected in workflow and output. This matters because breaches have far reaching operational, reputational, financial and legal consequences.

AI coding tools are neutral to your security concerns: they prioritize speed over security. And that shows.

Inline styles can appear everywhere and that complicates enforcing CSP with style-src later. Third-party CDNs where themes and fonts are pulled from can be shortcuts that also create a supply chain risk. For the human eye, complex Flexbox-reordening can be hard to catch.

This is exactly the hidden attack surface attackers aim for. Check that first.

In the Chinese gambling campaign that hot 150,000 sites, the attack scaled because sites lacked client-side monitoring. There was no detection of injected overlays or iframe manipulation. AI-accelerated development makes this worse: more code ships faster and fewer humans understand what's running.

How your defense can match the speed of AI

Accepting code you don’t understand isn’t secure. But to stop using AI coding platforms isn’t the answer either. Manual audits of every AI-generated file are impossible. Speed not only matters for AI coding tools, but also for your security defenses. To match AI speed, you need automated and continuous controls such as:

CSP testing in CI/CD to block inline styles on critical pages
Automated scanning to flag suspicious z-index, negative margins
SRI enforcement to include integrity checks for external CSS
Real-time monitoring to detect manipulation with client-side security platforms

Understanding the vulnerabilities of AI coding is the first step.

Putting guardrails in place isn’t a choice. It’s a necessity.

Conclusion

CSS is not only about styling a pretty page. Users trust what they see. If attackers control what the browser renders, they can manipulate what users see: hide buttons or warnings, overlay your content and replace entire pages.

That’s how CSS is part of your client-side security surface.

Lock down your CSS with CSP/SRI and monitor what loads to detect DOM changes in real-time. Don’t let attacker take the lead but match attack speed with automated controls. Even better: run ahead and add guardrails for AI-generated layout changes.

Prevent, detect, and defend.