84

I'm developing a web application and since it has access to a database underneath, I require the ability to disable the developer tools from Safari, Chrome, Firefox and Internet Explorer and Firebug in Firefox and all similar applications. Is there a way to do this?

Note: The AJAX framework provided by the database requires that anything given to the database to be in web parameters that can be modified and that anything it returns be handled in JavaScript. Therefore when it returns a value like whether or not a user has access to a certain part of the website, it has to be handled in JavaScript, which developer tools can then access anyway. So this is required.

UPDATE: For those of you still thinking I'm making bad assumptions, I did ask the vendor. Below is their response:

Here are some suggestions for ways of mitigating the risk:

1) Use a javascript Obfuscator to obfuscate the code and only provide the obfuscated version with the sold application; keep the non obfuscated version for yourself to do edits. Here is an online obfuscator: How can I obfuscate (protect) JavaScript? http://en.wikipedia.org/wiki/Obfuscated_code http://javascriptobfuscator.com/default.aspx

2) Use a less descriptive name; maybe 'repeatedtasks.js' instead of 'security.js' as 'security.js' will probably stand out more to anyone looking through this type of information as something important.

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
Brandon
  • 1,305
  • 1
  • 12
  • 16
  • 67
    Huh? That's not possible. Why do you want to do that? How do you intend to debug your code? **This will not make your app more secure**. – SLaks Sep 26 '11 at 18:20
  • 1
    Me thinks that it is the point of a plugin to overwrite/overrule standard browser capability or webpage programming. – Michael Jasper Sep 26 '11 at 18:21
  • 102
    Reminds me of the time where web developers wanted to **protect** their html/js source code by disabling the right-click on their page. – klaustopher Sep 26 '11 at 18:21
  • @klaustopher haha that was **always** easy to circumnavigate ^_^ – Naftali Sep 26 '11 at 18:23
  • The problem is the language we are using forces the use of javascript, thusly I need to prevent javascript editing – Brandon Sep 26 '11 at 20:13
  • 6
    Do you already have a solution in place that will prevent malicious users from accessing your program using a raw socket? – SingleNegationElimination Sep 26 '11 at 23:27
  • 9
    This question is very unfortunate; In some ways I'm glad that Brandon has asked it; The assumptions made are so bad that it's going to get a lot of attention. The bright point of all of this is that someone else might read this and learn just how bad those assumptions are; +1 for a learning opportunity! – SingleNegationElimination Sep 26 '11 at 23:38
  • 25
    +1: I don't understand the down-votes -- this question is asked well enough for us to see that the _goal_ of the question is misguided and an inappropriate response to a poorly-understood security objective. – sarnold Sep 27 '11 at 02:20
  • 1) user can evaluate any javascript code just from address bar; 2) user can look at the sources of the page and pretty print it with help of UglifyJS or any other parser; 3) user can fetch the sources with help of wget or another tool; 4) obfuscating is just a way to reduce the transfer size; – loislo Sep 27 '11 at 18:23
  • I'm aware but people are saying I'm uneducated and need to ask the vendor, thats what the vendor responded with. – Brandon Sep 27 '11 at 18:55
  • 1
    @Brandon did you send the vendor a link to this question....? – Naftali Sep 27 '11 at 19:54
  • I did not as most of the talk here is simply trashing myself or 4D I didn't feel it would help them much and would only serve to make them hesitant to answer – Brandon Sep 27 '11 at 20:39
  • @Brandon I do not believe it would make them hesistant, it would show them a hole – Naftali Sep 27 '11 at 20:50
  • I've often had some success de-obfuscating javascript in the console. Even if your vendor has obfuscated it, it will start with something like `eval(function(stuff))` and you can run `document.write(function(stuff))` to get the code. – Matt Lyons-Wood Feb 14 '14 at 05:33
  • 1
    This is somewhat possible. E.g. some time ago Facebook made it impossible for you to paste commands in console. – Salman A Mar 21 '17 at 12:24
  • @SalmanA, Here: https://stackoverflow.com/q/21692646/632951 – Pacerier Oct 11 '17 at 12:50
  • Possible duplicate of [How does Facebook disable the browser's integrated Developer Tools?](https://stackoverflow.com/questions/21692646/how-does-facebook-disable-the-browsers-integrated-developer-tools) – A-Sharabiani Dec 08 '17 at 21:43

17 Answers17

128

No you cannot do this.

The developer menu is on the client side and is provided by the user's browser.

Also the browser developer should have nothing to do with your server side database code, and if it does, you need some maaaaaajor restructuring.

Nighto
  • 3,994
  • 3
  • 23
  • 28
Naftali
  • 144,921
  • 39
  • 244
  • 303
  • While I agree the language we use does not allow the kind of restructure that would fix this – Brandon Sep 26 '11 at 20:11
  • 3
    @Brandon what type of language would have that big of a security hole??!! – Naftali Sep 26 '11 at 20:13
  • 4th Dimension. The structure they use is , use javascript to call the database function, respond to the html page using plain text, use a javascript function to handle the response. Therefore for instance if you use a function to tell the webpage whether they can go to another part of the site they can modify the javascript and allow themselves to go there anyways – Brandon Sep 26 '11 at 20:15
  • 1
    @Brandon and there is **no** server side code? that's pretty [inane](http://en.wiktionary.org/wiki/inane) – Naftali Sep 26 '11 at 20:16
  • There is server side code but its extremely limited and cannot effect the end user experience, it does help filter the entry but it takes paramaters in the form of web variables which if they remove the javascript filter they can add more web variables. – Brandon Sep 26 '11 at 20:18
  • 61
    @Brandon **NEVER** trust the filters on the client side. **Never** (I repeat again **NEVER**). Do more validation on the server side **always** no matter what you have on the client end. – Naftali Sep 26 '11 at 20:20
  • I am doing that thats just to illustrate the limited functionality of the server side code – Brandon Sep 26 '11 at 20:21
  • 4th Dimension web plugin. www.4d.com – Brandon Sep 26 '11 at 20:23
  • Again its written in 4d. 4D is a tool designed to be quick to deploy and is a database language, they have a plugin to deploy that database to the web. It contains all our legacy code so obviously it would be costly to switch away from – Brandon Sep 26 '11 at 20:26
  • 15
    It would be more costly to have everything stolen/erased I would Imagine. – Loktar Sep 26 '11 at 20:29
  • I however am not in charge of that decision – Brandon Sep 26 '11 at 21:17
  • 4
    I think you need to read more 4D docs. From what I can see of their website, there's plenty of server-side stuff, including PHP libraries. – ceejayoz Sep 27 '11 at 13:06
  • 1
    http://stackoverflow.com/questions/21692646/how-does-facebook-disable-browsers-integrated-developer-tools This is definitely possible. – TtT23 Feb 13 '14 at 11:14
  • 2
    @l46kok no. That is not a secure method – RyanS Feb 14 '14 at 14:23
  • 20
    This thread is such a mess; I can't believe what I'm reading. Are you in some sort of ultra secure environment where nothing is accessible except for the front end interface? Apparently not, since you're talking about regular browsers. Consider this: I can set up a proxy server and intercept all data coming from my computer. I can then *manipulate* and *bypass ALL* validation and obfuscation done on the client. We have servers for a reason. This is nuts. – iLoch Feb 28 '14 at 21:55
  • @Iwansbrough But I can obfuscate my client code as well, and randomize it making your detection of it a living hell, so that you won't even make that try making that effort. Don't speak in absolutes. – mjs Aug 10 '16 at 18:02
  • 2
    @momomo deobfuscation is not as hard as you think it is – Hamms Nov 02 '16 at 00:08
  • The console is not disabled there @Joshua – Naftali Jun 20 '17 at 00:52
  • 1
    There is a website which disabled all the ways to go in the developer mode. But I can still disable JS and goto the developer mode. – Zeeshan Ahmad Khalil Jun 29 '20 at 07:37
61

If your framework requires that you do authorization in the client, then...

You need to change your framework

When you put an application in the wild, where users that you don't trust can access it; you must draw a line in the sand.

  • Physical hardware that you own; and can lock behind a strong door. You can do anything you like here; this is a great place to keep your database, and to perform the authorization functions to decide who can do what with your database.
  • Everything else; Including browsers on client computers; mobile phones; Convenience Kiosks located in the lobby of your office. You cannot trust these! Ever! There's nothing you can do that means you can be totally sure that these machines aren't lying to cheat you and your customers out of money. You don't control it, so you can't ever hope to know what's going on.
SingleNegationElimination
  • 151,563
  • 33
  • 264
  • 304
  • 2
    I mean I think there are levels of hardware which aren't your own which are acceptable to trust in most instances - e.g. cloud providers – James Billingham Mar 16 '14 at 22:10
27

In fact this is somehow possible (how-does-facebook-disable-developer-tools), but this is terribly bad idea for protecting your data. Attacker may always use some other (open, self written) engines that you don't have any control on. Even javascript obfuscation may only slow down a bit cracking of your app, but it also gives practically no security.

The only reasonable way to protect your data is to write secure code on server side. And remember, that if you allow someone to download some data, he can do with it whatever he wants.

A-Sharabiani
  • 17,750
  • 17
  • 113
  • 128
Liberat0r
  • 1,852
  • 2
  • 16
  • 21
  • 27
    Please read the linked question, and answer carefully; The technique used by facebook protects innocent users from a specific sort of social engineering attack; it does not protect the application from a malicious user; For example, a malicious user could use their own build of chromium with `_commandLineAPI` with some other phrase, and have full access to the developer tools. None of this in any way invalidates the existing, older answers. – SingleNegationElimination Feb 11 '14 at 23:31
23

There's no way your development environment is this brain-dead. It just can't be.

I strongly recommend emailing your boss with:

  • A demand for a week or two in the schedule for training / learning.
  • A demand for enough support tickets with your vendor to figure out how to perform server-side validation.
  • A clear warning that if the tool cannot do server-side validation, that you will be made fun of on the front page of the Wall Street Journal when your entire database is leaked / destroyed / etc.
sarnold
  • 102,305
  • 22
  • 181
  • 238
  • 8
    Though perhaps it is worth mentioning that if the database stores your lunch options near the office, who prefers which food carts, and some algorithms to pick a lunch spot that suits everyone in your party, this is probably fine. If the database includes customer details, then you have no choice but to beg the vendor to teach you how to do server-side validation -- and failing that, make sure your boss knows the ramifications of the choice. – sarnold Sep 28 '11 at 00:07
  • 1
    You obviously don't know how cranky workers can get without their lunch. I suppose if they had this database and another one which can't be touched by the browser, but then what is the point of having the first database? – trysis Feb 12 '14 at 19:00
  • You think that now but wait till I change everyone else's lunch preferences to match my own >:] – Casey Feb 13 '14 at 17:41
  • 1
    I'm a food truck owner, and I'm going to change all your lunch preferences so you go to my food truck and not my competitors! – Mnebuerquo Sep 03 '17 at 11:38
21

No. It is not possible to disable the Developer Tools for your end users.

If your application is insecure if the user has access to developer tools, then it is just plain insecure.

Justin Niessner
  • 242,243
  • 40
  • 408
  • 536
  • Unfortunately the server has to respond to a javascript method for anything to happen and that javascript method can be modified in the language we have to use – Brandon Sep 26 '11 at 20:12
  • Actually it is: http://kspace.in/blog/2013/02/22/disable-javascript-execution-from-console/ Not saying this is a good idea though. – autra Feb 12 '14 at 10:54
  • 1
    @autra - Keep in mind, though, that "fix" will also disable the console for any developers working on the application (of course, you could add/remove the script as needed). It also wouldn't stop anybody from using the dev tools to modify the scripts on the page, remove the fix, reload, and access the console that way. – Justin Niessner Feb 12 '14 at 12:30
  • @JustinNiessner Well technically you couldn't use the dev tools because they're disabled... But yes this isn't security, it's hardly even obfuscation. – iLoch Feb 28 '14 at 21:57
  • 1
    @lwansbrough: (1) Disabling the **console** doesn't disable other developer tools (the ones that allow editing scripts on the page, for example). (2) Those techniques don't even disable the console, just make it incompatible by renaming the built-in global variables, etc. Justin is absolutely correct that it can be undone. Or a proxy server can just strip out the anti-console code in the first place. – Ben Voigt Aug 03 '15 at 14:35
  • @BenVoigt Didn't say it was a solid solution - I came here to see if it was possible to prevent regular users from executing code unknowingly, not to prevent other developers from executing code (that's a wasted effort!) The above method may be (have been?) effective at stopping self-XSS in the case of an attempted account takeover, though there's likely always a way around it. – iLoch Aug 06 '15 at 06:05
14

Don't forget about tools like Fiddler. Where even if you lock down all the browsers' consoles, http requests can be modified on client, even if you go HTTPS. Fiddler can capture requests from browser, user can modify it and re-play with malicious input. Unless you secure your AJAX requests, but I'm not aware of a method how to do this.

Just don't trust any input you receive from any browser.

trailmax
  • 34,305
  • 22
  • 140
  • 234
  • 3
    It's impossible to completely secure anything (AJAX or otherwise) on a client's machine. The user can always put a TCP proxy in the middle and use a self-signed certificate which they've installed on their machine, and the server will be none the wiser. – Matt Lyons-Wood Feb 14 '14 at 05:28
  • what I meant by "secure Ajax calls" is to implement encryption in JavaScript, on client side. But I'm not sure that's possible. – trailmax Feb 14 '14 at 10:14
  • Ah, ok. I'm sure it's possible (if [this](http://bellard.org/jslinux/) is possible anything is :P) but then I suppose you'd run into the same problems as software licensing/anti-piracy mechanisms in that if someone really wanted to crack it (and they had the expertise) then they could. – Matt Lyons-Wood Feb 15 '14 at 06:50
8

you cannot disable the developer tool. but you can annoys any one who try to use the developer tool on your site, try the javascript codes blow, the codes will break all the time.

    (function () {
        (function a() {
            try {
                (function b(i) {
                    if (('' + (i / i)).length !== 1 || i % 20 === 0) {
                        (function () { }).constructor('debugger')()
                    } else {
                        debugger
                    }
                    b(++i)
                }
                )(0)
            } catch (e) {
                setTimeout(a, 5000)
            }
        }
        )()
    }
    )();
Nerdroid
  • 13,398
  • 5
  • 58
  • 69
  • 3
    pressing Ctrl + F8 will disable breakpoints, so it can be bypassed – Aryeh Beitz Dec 09 '20 at 15:04
  • haha! but it is annoying. Is security through irritation a coined term? Same caveats as security through obscurity though. https://en.wikipedia.org/wiki/Security_through_obscurity#Criticism – dotnetCarpenter Jan 26 '23 at 21:04
4

Update at the time (2015) when this answer was posted, this trick was possible. Now (2017) browsers are mature. Following trick no longer works!

Yes it is possible. Chrome wraps all console code in

with ((console && console._commandLineAPI) || {}) {
  <code goes here>
}

... so the site redefines console._commandLineAPI to throw:

Object.defineProperty(console, '_commandLineAPI',
   { get : function() { throw 'Nooo!' } })

This is the main trick!

mumair
  • 2,768
  • 30
  • 39
3

https://github.com/theajack/disable-devtool

This tool just disabled devtools by detecting if its open and then just closing window ! Very nice alternative. Cudos to creator.

Paul Grei
  • 369
  • 2
  • 12
  • 1
    This still depends on the client not being able to manipulate the JS that's executed, and that's just wrong. It might make it slightly harder to do, but a simple proxy can block the devtool-disabler JavaScript from functioning. – Joachim Sauer Jan 24 '22 at 09:17
  • well as there is no other way arround this is the best solution i found. And just giving it a - points its without a reason. Its a valid solution like using script to disable key inputs. – Paul Grei Jan 24 '22 at 11:25
1

I found a way, you can use debugger keyword to stop page works when users open dev tools

(function(){
  debugger
}())
nuclear
  • 3,181
  • 3
  • 19
  • 38
  • 1
    This is nice but it works only if the user tried to open the page while the developer tool is opened, but if the tool is closed he can load the page, then re-enter the tool again while the page still displayed! – Hasan A Yousef Nov 10 '21 at 18:10
1

Yeah, this is a horrible design and you can't disable developer tools. Your client side UI should be sitting on top of a rest api that's designed in such a way that a user can't modify anything that was already valid input anyways.

You need server side validation on inputs. Server side validation doesn't have to be verbose and rich, just complete.

So for example, client side you might have a ui to show required fields etc. But server side you can just have one boolean set to true, and set it to false if a field fails validation and then reject the whole request.

Additionally your client side app should be authenticated. You can do that 100 thousand ways. But one I like to do is use ADFS passthrough authentication. They log into the site via adfs which generates them a session cookie. That session cookie get's passed to the rest api (all on the same domain) and we authenticate requests to the rest api via that session cookie. That way, no one that hasn't logged in via the login window can call the rest api. It can only be called form their browser context.

Developer tool wise, you need to design your app in such a way that anything that a user can do in the developer console is just a (feature) or a breaking thing. I.e. say they fill out all the fields with a js snippet, doesn't matter, that's valid input. Say they override the script and try to send bad data to the api calls. Doesn't matter, your server side validation will reject any bad input.

So basically, design your app in such a way that developer tool muckery either brakes their experience (as it won't work), or lets them make their lives a little easier, like auto selecting their country every time.

Additionally, you're not even considering extensions... Extensions can do anything and everything the developer console can do....

Ryan Mann
  • 5,178
  • 32
  • 42
1
$('body').keydown(function(e) {
        if(e.which==123){
            e.preventDefault();
        }
        if(e.ctrlKey && e.shiftKey && e.which == 73){
            e.preventDefault();
        }
        if(e.ctrlKey && e.shiftKey && e.which == 75){
            e.preventDefault();
        }
        if(e.ctrlKey && e.shiftKey && e.which == 67){
            e.preventDefault();
        }
        if(e.ctrlKey && e.shiftKey && e.which == 74){
            e.preventDefault();
        }
    });
!function() {
        function detectDevTool(allow) {
            if(isNaN(+allow)) allow = 100;
            var start = +new Date();
            debugger;
            var end = +new Date();
            if(isNaN(start) || isNaN(end) || end - start > allow) {
                console.log('DEVTOOLS detected '+allow);
            }
        }
        if(window.attachEvent) {
            if (document.readyState === "complete" || document.readyState === "interactive") {
                detectDevTool();
              window.attachEvent('onresize', detectDevTool);
              window.attachEvent('onmousemove', detectDevTool);
              window.attachEvent('onfocus', detectDevTool);
              window.attachEvent('onblur', detectDevTool);
            } else {
                setTimeout(argument.callee, 0);
            }
        } else {
            window.addEventListener('load', detectDevTool);
            window.addEventListener('resize', detectDevTool);
            window.addEventListener('mousemove', detectDevTool);
            window.addEventListener('focus', detectDevTool);
            window.addEventListener('blur', detectDevTool);
        }
    }();
0

You can not block developer tools, but you can try to stop the user to enter them. You can try to customize a right-click menu and block the keystrokes for developer tools.

Green
  • 486
  • 2
  • 11
  • 31
0

I am just throwing a random Idea maybe this will help.

If someone tries to open the developer tool just redirect to some other site.

I don't know how much this is gonna effective for you but at least they can't perform something on your site.

Amit Dagar
  • 167
  • 2
  • 8
0

You can't disable developer tools

However...

I saw one website uses a simple trick to make devtools unusable. It worked like this - when the user opens devtools the whole page turns into blank page, and the debugger in devtools is stuck in a loop on a breakpoint. Even page refresh doesn't get you out of that state.

Pawel Veselov
  • 3,996
  • 7
  • 44
  • 62
U20
  • 26
  • 1
  • 5
-1

Yes. No one can control client browser or disable developer tool or debugger tool.

But you can build desktop application with electron.js where you can launch your website. Where you can stop debugger or developer tool.

Our team snippetbucket.com had build plenty of solution with electron.js, where similar requirement was their. as well restructure and protect website with many tools.

As well with electron.js many web solution converted and protected in well manner.

Tejas Tank
  • 1,100
  • 2
  • 16
  • 28
  • What stops a user from debugging (natively) the Electron application, figuring out the URL that's being opened and opening that with a normal browser or modified Electron build? – Joachim Sauer Jan 24 '22 at 09:18
  • This feels like a conflict of interest. Why do you mention your site in so many answers? – Mous May 16 '22 at 00:32
  • Easily works with finished product generation of exe and its works. we tested it. under it we have more control to resolve this kind of issue. as we have worked. we speak – Tejas Tank May 19 '22 at 11:11
-2

You can easily disable Developer tools by defining this:

Object.defineProperty(console, '_commandLineAPI', { get : function() { throw 'Nooo!' } })

Have found it here: How does Facebook disable the browser's integrated Developer Tools?

Community
  • 1
  • 1