Protect yourself against a pure CSS data stealing attack called Exfil

Martin Brinkmann
Apr 2, 2019
Updated • Apr 2, 2019
Firefox, Firefox add-ons, Google Chrome, Google Chrome extensions

CSS Exfil Protection is a browser extension for Mozilla Firefox and Google Chrome that protects data against CSS Exfil attacks.

Internet users who have a good understanding of online security know that JavaScript is a great technology but also something that can be used in attacks. There are plenty of solutions available to deal with JavaScript-based attacks including using content blockers like uBlock Origin, extensions like NoScript that block JavaScript executions, or disabling JavaScript outright (the latter is not very practical).

An attack, named CSS Exfil (from exfiltrate), uses CSS to steal data. Mike Gualtieri, the researcher who discovered the vulnerability, published several proof of concept attacks designed to steal usernames, passwords, and other data on web pages it is used on.

css exfil vulnerability tester

Mike Gualtieri created a vulnerability tester that returns whether the web browser is vulnerable to CSS Exfil attacks. Just visit the web page in question to see if the browser is vulnerable or not. The page is just testing the vulnerability but not abusing it in any way.

What makes the attack particularly problematic is that it does not rely on JavaScript and that browsers don't offer any form of protection against it.

CSS Exfil Protection is a browser extension that adds protections against CSS Exfil attacks to web browsers. Designed for Firefox and Chrome, the extension should work in Firefox-based or Chrome-based web browsers such as Opera or Vivaldi as well.

The extension "sanitizes and blocks any CSS rules which may be designed to steal data". Note that you may run into issues on sites that use these rules for legitimate purposes. The developer plans to introduce support for a whitelist in future versions to address the issue. An option to toggle it on or off globally is provided already.

Just install the extension in a supported web browser to protect your data against attacks exploiting the issue. You may want to visit the vulnerability tester page again to see if you are indeed protected.

css exfil protection

CSS Exfil Protection adds an icon to the browser's main toolbar. The icon shows the number of blocked CSS rules to indicate that content was blocked on the page; this does not necessarily mean that the page was used in an attack as the CSS rules may be used for legitimate purposes as well.

CSS Exfil Protection is open source. You can browse the code on the project's GitHub page.

Closing Words

The CSS Exfil Vulnerability highlights once again that there is always a chance that new technology that is supported by browsers can be abused.

software image
Author Rating
3.5 based on 11 votes
Software Name
CSS Exfil Protection
Software Category
Landing Page

Tutorials & Tips

Previous Post: «
Next Post: «


  1. namaram said on June 7, 2020 at 2:11 am

    “What makes the attack particularly problematic is that it does not rely on JavaScript and that browsers don’t offer any form of protection against it.”

    First thing on the poc test site : “This page requires JavaScript.”

    1. Anonymous said on February 9, 2021 at 12:45 am

      There is a very big difference between “The attack does not rely on JavaScript” and “This test page requires JavaScript”.

  2. na said on November 10, 2019 at 7:38 am

    the plugin is the back door, there is no vulnerability

  3. metoo said on June 2, 2019 at 7:48 am

    Got 2 hits on: Their page is certainly trying to efil data

  4. Steve said on April 4, 2019 at 6:55 am

    I’m trying the add-on and found a couple of things:

    – Page rendering is affected even if I deselect “Enable CSS Exfil Protection?” checkbox. Why? It mainly affects buttons and input text fields. This is on Firefox 66.0.1.

    – I could not found a website where I get a hit. Maybe, that is good in the sense that it won’t interfere.

  5. Jason said on April 3, 2019 at 5:14 pm

    Noob here.
    1.If you block 3rd party CSS with uMatrix and enter passwords/credit card details only on popular sites.(Youtube,Amazon,Protonmail etc.) would you still be prone to this vulnerability?
    2. Why Google developers are yet to address it? This is known for at least more than a year if my memory serves.
    Thank you!

    1. thebrowser said on April 4, 2019 at 2:07 am

      1. Yes, since the CSS loaded from the 1st party may be using this vulnerability. This is however very unlikely to happen in any of the major companies’ websites for two reasons. First of all this is code that runs in your machine and can be easily reviewed by anyone, and secondly, while this vulnerability exists, the owner of the site has to actively take steps to implement it. Can you imagine the shitstorm that would fall down on Amazon, Google, Youtube, etc if they were caught doing this? This would be WAY beyond the Facebook’s recent f*** ups, since there is literally no way to deny involvement by any oversight.

      2. The browser extension has been developed by the very same researcher who published this. Up until now it was not really clear the implications this could have, so the browser developers may have just dismissed this. However since the vulnerability is at the very core of how the modern web works, I’d expect to see steps taken from these companies to address this.

      1. Jason said on April 5, 2019 at 3:02 am

        Wow, glad that I asked here. This is the answer I was looking for. Thank you for your valuable time. Much appreciated.

  6. Skotty said on April 3, 2019 at 6:36 am

    No CSS Exfil Protection for the chromium-based Opera available at this time.

    1. Fuzzi said on April 5, 2019 at 1:32 am

      Load the Chrome version into Opera using this extension:

  7. Dave said on April 3, 2019 at 2:15 am

    Hmm, the TOR browser returned vulnerable once the javascript was allowed to run. Odd FF 66.0.2 did not require Javascript to be allowed.

    Both are using the noscript addon.

    1. Tom Hawack said on April 3, 2019 at 2:50 am

      @Dave, the testing page requires javascript, as mentioned on that page :

      “If the vulnerability doesn’t involve JavaScript, why does the vulnerability tester require JavaScript?
      While the CSS Exfil attack doesn’t require JavaScript to function, this page requires a few lines of JavaScript to check to see if the exploit succeeded in loading the images.”

  8. didimisssomething? :S said on April 3, 2019 at 1:21 am

    My browser wasn’t vulnerable according to this test webpage:

  9. Darren said on April 3, 2019 at 1:07 am

    “and that browsers don’t offer any form of protection against it”

    Seems like a huge problem. Why no action on this other than a 3rd party solution. I don’t get it.

    1. thebrowser said on April 4, 2019 at 1:59 am

      This 3rd party solution was developed by the same researcher who noticed and published this vulnerability, and from there the browser makers will implement it. Hopefully, at least, although seems likely since it’s a vulnerability not on the browser but on the underlying technology used by the web itself and affects everyone.

  10. Supergirl said on April 3, 2019 at 12:08 am

    @Martin – Hi,There!
    You Wrote:

    “Note that you may run into issues on sites that use these rules for legitimate purposes.”

    Okay…Can you clarify what Exactly you mean by this?

    See…Im thinking there is NEVER a legitimate purpose to sneak onto my computer & inspect/steal info.
    when theres always the option to ask me for it.

    Perhaps you meant that CSS has a legitimate purpose…?

    Or maybe this was just a throw away remark to cover all bases..?

    Please explain..? Thank you.

    P.S. I installed Gargle Analytics opt-out in every profile of every browser…
    I can no longer see any ads here. *sigh*

    Please dont feed the beast…
    Is there a way you could get ads Without using the sinister octopus…?

    1. Supergirl said on April 7, 2019 at 2:19 am

      @ FAKE —> Supergirl said on April 3, 2019 at 12:08 am

      Either that or I have multiple personalities…….

      I so totally didnt write whats above this.

      I think Ill stop using this handle as this mailbox is full now anyways. Or do i just like to lie about what i type on this website.

      After 9-11 I looked in on bomb making & jihadi websites…..Just out of curiosity. You know, know thine enemy.

      1. Supergirl said on April 8, 2019 at 5:03 am

        Supergirl said on April 7, 2019 at 2:19 am

        @ FAKE —> Supergirl

        Thats cool at least you admit youre a Fake..

        How sad for you.

      2. Supergirl said on April 9, 2019 at 5:51 am

        If you understand America…..this will describe me.
        Im a liberal democratic type. Love Al Gore & Hillary.
        Despise RReagan.Nixon GWB & U-Know-Hooo!

        Im really,REALLY sick of anti-white rascism.
        The Gov in Virginia(?) did black face in college in 1986..Big deal.
        Being called on to resign for that, idiotic..this nonsense is why liberals lose.
        Stick to the important stuff.Geeze!

        That’s why i’m a feminist..

        I know… I know… too many of you think youre smarter but youre not!

        Me Supergirl needs to prove that she is smarter than anyone here… please go on show us….

        Either that or I have multiple personalities……

        I so totally didnt write this.

        I think Ill stop using this handle as this mailbox is full now anyways. Or do i just like to lie about what i type on this website.

        supergirl said on March 8, 2019 at 5:13 am

        I think the GA opt-out is very likely to be worthless. I prefer to just block GA scripts, then I don’t have to wonder.

        True dat!
        But at least I have a fig-leaf when Imo my ‘Wide Open’ Profile…for Ghacks &
        Craigslist so I can click on the reply button there {Yes, Its Google!} to respond to the ‘Great Deals’..LoL

        I have to protect my online reputation here on this website.

        You’re the best at everything you do! Too bad all you do is disappoint.

        Thats cool at least you admit youre a Fake..

        How sad for you..

      3. Real Supergirl said on April 13, 2019 at 6:24 pm

        Either that or I have multiple personalities……

        I think Ill stop using this handle as this mailbox is full now anyways. Or do i just like to lie to myself here on this website.

        Id like to apologize to ALL for what ever it is I did to set off this jealous nitwit in the first place.
        Also Thanks to those who have kept a sense of humor about it.
        I feel like royalty having my own personal ‘Foole”….

        I have Always filled out the email addy….

        Last time from ;Real Supergirl’..except to point out the ‘Foole
        Lets see if i can stop with my OWN lies about what i post here on this website.
        Last time from ;Real Supergirl…

        Thats cool at least you admit youre a Fake..

        How sad for you.

    2. thebrowser said on April 3, 2019 at 6:12 am

      This method specifically uses a valid CSS selector that could and probably is commonly used across a wide range of websites, for example for CSS-only dropdown menus or any other style that directly involves input fields on a form. The fact that is commonly used and that it is hidden is what makes this dangerous. You can see from the technical docs that it specifically targets using these formula [attribute=value] and some variations using other selectors like ^~| etc. common to CSS.

      This also works by hiding the input fields which would be a red flag for anyone inspecting the code (since it runs in your machine you can do that at anytime), but some server-side web technologies like some nodejs packages use this method also very commonly for well intended purposes…

      The only method I found to fully bypass this issue without installing the addon was to… err… disable CSS entirely with uMatrix (blocking the images only does nothing, since the vulnerability is loaded within the CSS). For cross-origin requests uBO was enough since the @import at the top of the CSS file creates a new HTTP request which is very easy to detect and block.

      1. Martha Stewrat said on April 3, 2019 at 9:10 pm

        Thank you …
        So this was just an over looked unintended consequence then ?

      2. thebrowser said on April 4, 2019 at 1:56 am

        It most certainly looks like it is, after all this method is quite devious in sneaking on how a very popular technology works under the hood… I’d expect some move from the major browsers into adding an built-in protection for this, since it’s a fundamental vulnerability that affects all of them, but let’s see how it turns out to be.

  11. fukCSShacks said on April 2, 2019 at 1:42 pm

    Old news, Here’s the ubo fix for this “POC” if anyone’s still interested —, testForStyle, noopFunc)

    1. Marcus Buttfikler said on April 2, 2019 at 11:15 pm

      Martin, can you delete this post? **** like Jason are using this useless adblock filter that does nothing to stop the actual vulnerability.

      1. Jason said on April 3, 2019 at 5:24 pm

        @Marcus: Did you just call me a foul name? Nice. What a big man you are.

    2. Harro Glööckler said on April 2, 2019 at 7:49 pm

      Rofl nice, this is the equivalent of putting black tape over the “check engine” light. Killing the messenger fixes every situation, right?

    3. Jason said on April 2, 2019 at 5:21 pm

      Thank you! That worked nicely. I prefer doing this stuff through uBlock Origin instead of adding more browser extensions.

      1. Doc said on April 2, 2019 at 10:45 pm

        As other commenters have stated, this is just a uBlock Origin rule to “break” the browser test on Mike Gualtieri’s page; this does NOT protect you from the exploit, it just prevents his page from working!

      2. Anonymous said on April 2, 2019 at 6:44 pm

        didnt you read any of the previous replies? /facepalm

      3. Jason said on April 3, 2019 at 5:23 pm

        @Anonymous: No, I didn’t read any of the replies because I actually posted my comment before any of theirs were visible. But it seems it took several hours for my own comment to become visible, and so it now appears far down the thread. Facepalm yourself next time.

    4. Emanon said on April 2, 2019 at 5:20 pm

      That doesn’t fix anything, cause that rule will only change the test page value, it won’t protect you from the exploit whatsoever.

      No offense of course, but I though you should know.

      1. Tom said on April 2, 2019 at 7:22 pm

        It is the perfect fix, not running the vulnereability in your browser is a sure fire way to prevent it before it happens, ofcourse the true fix is with the browser devs only, another ungrateful smartass.

    5. Pants said on April 2, 2019 at 4:57 pm

      Stop being severely idiotic. No-one is interested. There is zero point and it would give anyone doing it a false sense of security.

      Your filter, as is, would only work on the one site, the one which is designed as a test and is not actually malicious. Any testing using this site would result in a true negative (opposite of a false positive). Even if you did make the filter global, any real world attack could use any naming convention.

    6. Anonymous said on April 2, 2019 at 3:41 pm

      What the hell, that doesn’t do anything, except for blocking Javascript on the one site that simply explains the exploit. If you don’t know what you’re doing, please don’t misinform others.

    7. Tom Hawack said on April 2, 2019 at 2:30 pm

      That blocks the test, not the vulnerability.

      1. fukCSShacks said on April 2, 2019 at 7:26 pm

        Hence the name “ubo fix” DUH!!!!!!

      2. Tom said on April 2, 2019 at 7:17 pm

        Vulnerability can only be fixed by Chromium devs, captain obvious.

  12. Damien said on April 2, 2019 at 1:35 pm

    Hey, in firefox my browser isn’t vulnerable without installing the extension. I guess one of my installed extension already did the job…

    1. max3 said on February 6, 2021 at 5:33 pm

      I know this is an old article but… for me the key for me is uMatrix. I use uMatrix with CSS blocked in the top row (inherited from “ALL”, pink, not red) with only first party enabled the whole way across (so CSS is on only for and no other domains). I get “not vulnerable” with or without CSS EXFIL Protection add-on. If I disable uMatrix, clear cache and refresh I get “vulnerable”. If I re-enable uMatrix, clear cache and relaod I get “not vulnerable. The difference is clearing cache, if I only hit the reload button nothing changes from the previous test. I use Dark background and Light Text add-on so all webpages look basically the same without much CSS going on.

    2. Sanjay Nayak said on April 5, 2019 at 7:13 pm

      Replying so that I get an alert when Damien finds out the add-on which fixes the vulnerability for his browser.

    3. Cigologic said on April 3, 2019 at 1:06 am

      @ Damien, Klaas Vaak —

      That CSS Exfil Vulnerability test-page requires JavaScript & the jQuery library to load the CSS injection test correctly:

      If JavaScript &/or jQuery is blocked via addon(s) &/or browser pref(s), the test won’t load properly, hence giving a FALSE-NEGATIVE — ie. the test will misleadingly declare the browser as not vulnerable. This doesn’t imply that the browser is indeed immune to the said CSS injection attack, since CSS injections do not depend on JavaScript or JavaScript libraries.

      Over here, the CSS Exfil Vulnerability test-page shows my browser as not vulnerable — even though JavaScript is enabled & all addons are disabled, as well as after clearing cache, & reloading the test-page.

      However, redoing the test using a brand-new browser profile with factory-default user prefs & no addons, the test page now shows the browser as vulnerable — ie. it successfully loaded the CSS injection test-script (presumably non-malicious in this case).

      As such, it seems that at least 1 of the modified user prefs in my “hardened” browser profile is preventing the test-page from correctly loading the self-hosted jQuery library, hence the false-negative wrt CSS injection test.

      1. Klaas Vaak said on April 3, 2019 at 3:03 pm

        @Cigologic: thanks for that explanation. I have 2 questions then:
        * where is the Javascript switch in FF? I thought it would be under Privacy/Security, but the interface keeps getting changed so I cannot find it anymore.
        * do you know what to add to uBO to block this CSS problem and avoid having to install yet another extension?

      2. Tom Hawack said on April 3, 2019 at 7:36 pm

        @Klaas Vaak, the only Javascript switch in Firefox is within about:config : javascript.enabled.

        Users of uBlock Origin may also access a Javascript switch from :

        uBO Dashboard > Default behavior > Diasble Javascript (this is a default setting, refer to

        This said I still don’t understand how you and Damien get the results you mention on the CSS Exfil test page. Mystery…

      3. Klaas Vaak said on April 4, 2019 at 7:24 am

        @Tom Hawack: thanks for replying Tom :-)
        I knew about the uBO Javascript setting. What I don’t know is how to set a block in uBO against this CSS vulnerability – several people here mention it.

    4. gazoo said on April 2, 2019 at 7:15 pm

      @Damien: I’m on the same page as Tom Hawack on this. Very curious as to what’s blocking the CSS exploit (as it could be useful for zero-day stuff). I have a good number of extensions aimed at privacy/tracking protections, lots of about:config changes… FF still shows as vulnerable to this exploit unless I activate ‘CSS Exfil Protection’.

      I wonder if you have an extension already doing some kind of CSS override (look and feel stuff).

      Will check in on the comments from time to time. Seems like a good mystery:-)

      1. Kalandria said on April 3, 2019 at 10:11 am

        @gazoo: I’m only using uBO on Firefox and my browser is reported as not vulnerable even after I turn it off during the test. I think it has nothing to do with certain extension but probably some “about:config” tweaks. My guess, it is probably because I enabled “privacy.firstparty.isolate”. I can’t think of anything else because I don’t remember I’ve ever done other tweaks but this.

      2. Klaas Vaak said on April 3, 2019 at 2:58 pm

        @Kalandrai: I have that one disabled (i.e. set at “false”) and still get “not vulnerable”.

    5. Klaas Vaak said on April 2, 2019 at 3:01 pm

      @Damien: same here, don’t know which extension is responsible.

    6. Tom Hawack said on April 2, 2019 at 1:49 pm

      @Damien, now that’s interesting. Could you investigate and try to discover what extension and/or setting of yours protects your Firefox from this CSS Exfil vulnerability?

      1. Klaas Vaak said on April 2, 2019 at 3:03 pm

        @Tom Hawack: have you tested your vulnerability? I would not be surprised if it is uBO, which you use too.

      2. Tom Hawack said on April 2, 2019 at 3:28 pm

        @Klaas Vaak, I’m in the opposite situation to Damien :

        without the ‘CSS Exfil Protection’ extension for Firefox OR with but disable from about:addons OR unchecked from its toolbar button the test page shows ‘Your browser is vulnerable!”.

        With the ‘CSS Exfil Protection’ extension for Firefox is installed AND enabled AND toolbar button checked, the test page shows “Your browser is not vulnerable!”

        I have several protection tweaks and extensions so if someone should be able to be protected from this CSS Exfil vulnerability it is obviously my Firefox as it is. You and Damien do not use the dedicated ‘CSS Exfil Protection’ extension for Firefox and yet the test page indicates no vulnerability : that’s what puzzles me.

      3. Damien said on April 2, 2019 at 2:58 pm

        I will try to check (disabling/enabling) extensions one by one in my firefox to find which one is already doing the job. But you’ll have to wait next week-end to get the results as I am busy during the week (work)…:-)

  13. Tom Hawack said on April 2, 2019 at 1:29 pm

    I’ve installed ‘CSS Exfil Protection’ extension for Firefox ever since it was launched on the basis of the vulnerability it addressed without ever understanding that very vulnerability.

    As the article states it, “[…]new technology that is supported by browsers can be abused.”
    You said it, brother (not my typical wording but helpful to emphasize!).

    Romeo and Juliet, 21st century : Romeo as the Web user, Juliet as the new technologies : love leads to drama, sometimes. Darn.

  14. Christoph Wagner said on April 2, 2019 at 12:38 pm

    It should probably be mentioned that this is from the beginning of 2018 and not new as written here.

    1. Martin Brinkmann said on April 2, 2019 at 2:12 pm

      You are right, thanks!

Leave a Reply

Check the box to consent to your data being stored in line with the guidelines set out in our privacy policy

We love comments and welcome thoughtful and civilized discussion. Rudeness and personal attacks will not be tolerated. Please stay on-topic.
Please note that your comment may not appear immediately after you post it.