Here is how to stop websites from blocking devtools

Some websites are blocking devtools with malicious JavaScript, so here is how to stop that without disabling JavaScript.


By. Jacob

Created: 2023-10-07 22:05

Browsing the internet with JavaScript enabled is often a matter of choosing between the plague and cholera; there exist numerous ways a malicious developer can hijack users input and detect and sabotage the use standard browser features, and it can be tremendously difficult if not impossible to block such irritating malicious code entirely – however, this is mainly due to the many different contexts and ways in which such malicious code is implemented. The web is luckily based on open standards, so if it runs in a browser, it can also be blocked and even changed.

Preferably all sites would work with JavaScript disabled. Developers could maintain a JavaScript-free site as a show of "good will" towards their users. Unfortunately they do not necessarily do that, and the mere fact they do not can often be a sign of malicious intent. There is no technical reason why a website should not work without JavaScript, except perhaps for developer incompetence. Front-end frameworks like vue.js and react should not be an excuse.

Besides, a user who is irritated or sufficiently motivated can of course inspect your code and block your nasty malware from running on their systems. Out right disabling is rarely convenient, because it will just break too much.

Websites blocking the use of devtools

I recently noticed some sites have started to detect the use of devtools. I did not even realize that was possible, but here we are – another nasty way websites can mess with their users. Of course, the easiest way to prevent detection of developer tools is to prevent the detection code from running in the first place, and of course the detection code is again JavaScript. It seems JavaScript is inherently malicious in some ways.

Luckily, many such malicious developers seem to be somewhat incompetent or lazy themselves, and instead of self-hosting their code, they just include a third party detection scripts as an external dependency. Doh!

This is easily blocked by enabling uBlock annoyances filter in uBlock origin or Brave. The specific filter can be inspected here:

A Complaint against Brave: This brings me to a major complaint against the Brave Browser; the fact that there is no direct link to the available lists from within the settings. It took me a very long time just to locate the specific uBlock annoyances list just to inspect it and determine whether I wanted to enable it or not.

One particularly nasty script is located at, luckily it is blocked by the uBlock annoyances filter. Interestingly, the developers even put the code on GitHub for public inspection:!

Manually stopping code from running

When the detection code is not blocked by such existing lists, we can still inspect the website code on our own and manually create a rule for it. E.g. Brave has a text field for "custom rules" in its settings that we can use. A basic rule could be adding an absolute URL (one per line) to the resource you want to block.

This is not foolproof, as the URL might still be opened with window.location.href and similar abusive mechanisms. So we can not use it to block "Popunders".

However, many such popunders typically go to entirely malicious domain names, so if the host itself is malicious, simply add it to your host file in /etc/host:

I usually prefer not to manually do that and instead rely on browser-level filters, because manually maintaining these block lists yourself can be a huge amount of work. In some cases, where I just want to permanently block a specific malicious host I will go ahead and just DNS block it in my host file.

On Windows the host file is located in c:\Windows\System32\Drivers\etc\hosts, but for Mac and Linux it is stored at /etc/hosts. You can use this trick to inject your own code into websites without having to use Tempermonkey or similar browser plugins.


Tampermonkey can be used to fiddle with the website code before or after the malicious code is activated, which gives us rich opportunity to get rid of the offending code manually.

It opens some really interesting ways to intercept and block malicious JavaScript, although it is quite time consuming and you probably need to specifically create your code targeting certain sites in order to have it work.

Knowing that console.log was probably one way to detect devtools, I tried simply doing a universial console.log = undefined, but that ended up irritating me when I needed it myself, and also, it did not work quite as I was hoping.

I think uBlock filtering is the best way to deal with malicious JavaScript. Trying to sabotage the functionality in existing scripts it is too much custom work.

Tell us what you think:

  1. We can not handle HTTP POST data from JavaScript, but we can still access the data while it is in the HTML form.
  2. getElementById should be used to select unique elements in a HTML document. Selected elements can be manipulated with JavaScript.
  3. Should you use querySelector or getElementById?; querySelector is more flexible, and able to perform more complex selections.
  4. the keydown event is not an ideal way to detect text-input by the user; instead you should consider using the input event.

More in: JavaScript Tutorials