New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 39 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature

Sign in to add a comment

DevTools: Combat self-xss

Reported by, Feb 20 2014

Issue description

Chrome Version       : All
URLs (if applicable) :

Please see

If the following code:

Object.defineProperty(window, 'console',{ get : function() { throw 'Nope' } })


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

is run on the page, the browser console is disabled for that page.

As explained in the StackOverflow link, what this does is that if the code runs before the console is, the subsequent console VMs that are loaded use a flawed version of the console (or console._commandLineAPI) commands, which break due to the exception throw and don't let the user run anything in the console.

As far as I can tell, one cannot avoid this short of disallowing the console-destroying javascript from running.

While we might want to consider giving websites *some* power in disabling the console (read: allow them to lock it such that big warnings are shown if you wish to unlock it, and one can unlock permanently via the prefs if they want, but I doubt that this will really stop self-injection of code), this is too much power, and we probably should look for a way to avoid this sort of code from being effective.

One way to do this is to separate the console command line API into a browser-context (inaccessible from the window) variable, and duplicate all the member functions from `console` and `console._commandLineAPI` as member methods. Then, replace the VM `with` statement with one that uses these variables.


Comment 1 by, Feb 24 2014

Patch that disallows redefining `_commandLineAPI`:
Labels: Needs-Feedback
Can you please provide a sample test case/HTML file so that would be helpful for QA to reproduce the issue from our end.

Comment 3 by, Feb 26 2014

Re: comment 2, see <>. Just running this on a page is enough to effectively block the console:

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

Test case:


I disagree with the notion that we should prevent this, though. All it will do is start an arms race. I linked to the patch purely for reference.
Regarding the arms race bit, it may make sense to give website owners a sane way to disable the console, which can be overridden by devs who want to use the console for legit purposes. (show the appropriate red warning signs, with specific focus on self-XSS maybe?)

Facebook was decent enough to provide a way to turn this off in the page linked in the message. If other sites start using this without that decency, it is *really really hard* to get the console back. Sites should not be able to take developer tools almost irrevocably away from the developer.
#4 I don't think website owners should have a way to disable the console, but likely first-time use of the console should prompt the user with appropriate warnings.
That's a pretty decent idea :)

Comment 7 by, Mar 6 2014

FYI, Netflix just started doing the same thing Facebook has been doing.

Comment 8 by, Mar 6 2014

Except that Netflix didn't provide an opt-in like Facebook did.

If this truly is a serious attack vector (and Facebook's explanation at certainly seems reasonable and sincere), then it's best to get out in front of this before every major tech company assumes it's a security norm to just block developer tools as a matter of course.

Make a browser-level flag a site owner can turn on, but that the developer can always turn off (persistently) if they want to (with an appropriate warning). Bake it in quickly, then let devs use shims while the browser makers agree on a standard.
I agree with konklone here. I also filed a parallel bug for that feature for Firefox here:
And to be clear, the warning would have to be directed not just at developers, but normal users, who might be following hostile instructions. 

That's the same line Facebook is trying to walk, and it might be useful to open a dialogue with them to figure out how well it's worked.
Agreed. It would need to be scary enough, whilst not scaring off the devs, though they should of course still have to read it.

Like Firefox about:config. The "void your warranty" bit is pretty scary to most, however as a developer I'm not afraid of going there and tweaking.
For what it's worth the route favored by the Firefox devtools team is to have a CSP directive allowing a site to turn off anywhere that JS can be executed. When toggled, console will point to an MDN article which explains the situation and refers to a pref that will turn off the CSP directive.
came here to point out that `Object.getOwnPropertyDescriptor(console, "_commandLineAPI")` returns an descriptor such `{value:CommandLineAPI, writable:true, configurable: true, enumerable: true}` which is an absolute lie since such property not configurable, not enumerable, and also not writable.

I wonder if anyone else here is concerned with the fact that console has such magic inconsistent properties  but it can be easily redefined in the global scope ... I see both as a problem.

I'd rather make console something optionally available, immutable in the global scope, and solve also inconsistent descriptors for its properties **adding** a generic "dev:consoleopened" event or something similar usable via `window.addEventListener`

my 2 cents
P.S. the event was in order to let site owner inform with a message the user that using console might hurt them, loose data, hack their own account and stuff like that ... keeping the browser owner the only one that can decide that the console should never show up (latter option ... pointless, but at least it's under the user browser control and not the randomly hosting site)

Comment 16 by, Mar 28 2014

I've just been hit by the patch. I'm using my custom snippet to make working with AngularJS apps nicer:
The gist uses console._commandLineAPI.

I understand the decision to disallow pages like Facebook to mess with a console but it would be useful to be able to unlock it for debugging purposes so that e.g. snippets have access to this API. Perhaps just exposing this API to snippets somehow?

Removing this feature makes debugging harder...
Today (moments ago) Delete comment

Comment 17 by, Mar 28 2014

For reference, this is the code change:

And this bug is duplicate of  issue 349993 .
Labels: Cr-Platform-DevTools Cr-Platform-DevTools-UX
Status: Untriaged
Summary: DevTools: Combat self-xss (was: Don't use the context of the console for running scripts in the console.)
Hi all!  Sorry for the radio-silence on this ticket. Since it wasn't tagged with a DevTools label it didn't get picked up for a while.

-  Issue 349993  was the ticket discussing that Chrome's console can be blocked with JS. That's a bug in the product, so it was fixed. 
- This issue is discussing Self-XSS, so I'm retitling it.

First up, the question is if action is necessary. 
Facebook does a combo of bigass-red-warning and console block. ( Is the bigass warning enough?  I personally feel it may be.

Next, how to allow sites to opt-in to blocking self-xss?  
Mozilla floated a CSP extension here:
In Chrome we've discussed a method that doesn't expose a new primitive to the web. It works like this:
* If user is considered a "first-time" user of devtools (heuristic TBD)
* and *pastes* javascript into an execution context (console/watches/snippets)
* Chrome detects that and throws up a confirmation prompt, something like… "You may be a victim of a scam. Executing this code is probably bad for you. [Okay] [I know what I'm doing, continue]."

This would be similar to how javascript: code is handled in the URL bar in Chrome. If it's typed in it works, if it's pasted it fails.  An extra benefit of this approach is that the protection is extended beyond Facebook/Netflix to all sites that aren't smart enough to hack the console or set up a CSP header.


In that case we need to make sure to show the warning whenever *anything* is pasted in the DevTools console.

When browsers made pasting e.g. `javascript:alert(1)` in the address bar a no-op, attackers quickly turned to social engineering to make the victim type Ctrl/Cmd+L (to focus the address bar), then `j`, and then paste `avascript:alert(1)`, which is enough to bypass the protection. This time we need something more strict.
Just to keep track, the Firefox bug for this is on, and the meta bug for this issue is here:

I like the copy-paste detection, I'll see if I can make that happen for Firefox as well.
Status: Started
Alright, the heuristic I'm going to use is:

If user has console history with more than 10 entries, paste succeeds. Otherwise, prompt appears:

"You may be a victim of a scam. Executing this code is probably bad for you. \n\nType 'always allow' in the input field below to allow this action".

Typing "always allow" disables prompt forever. Any other action prevents default (paste / drop).
Project Member

Comment 22 by, Apr 10 2014

The following revision refers to this bug:

r171275 | | 2014-04-10T14:06:27.713679Z

Changed paths:

DevTools: better address console self-xss.


Review URL:
Labels: Cr-Security-UX
pfeldman's patch in #22 is probably as far as we want to go with this? Should we set this bug to Fixed?
Actually I take that back; that UX needs review — even if only because it requires the user to input the *English* string "always allow", even if they are a native speaker of some other language. We should revert and then re-land that CL when we have something more baked.

At most I'd like to see just buttons, e.g.:

    [ Paste Anyway ]    [[ Back To Safety ]]

And to have the browser remember the choice at least per-session and possibly permanently.
If it's just a button, people are likely to click through blindly, most are conditioned to do that anyway. Something like this requires them to read the message. Joe Walker wrote a post( that has a rather nice analysis of this.

In the ongoing Firefox version of this change we've made the warning and the string part of the l10n strings, so English shouldn't be a problem. I guess this can be done here, though I don't know how Chromium handles l10n.

Comment 27 by, May 1 2014

Re #16: Ahh, I've missed _commandLineAPI wasn't removed entirely but just moved to window with a slightly changed name. My use case works fine then.

Comment 28 by, May 1 2014

Please do not add new security UX without checking in with security first! Also, please send this new warning through the normal UI review process (I am assuming that hasn't been done).

Some issues I see:
* As palmer said: the internationalization is a problem and calls for a revert.
* The dialog should have a custom headline that pertains to the warning instead of "The page at chrome-devtools://devtools says:" 
* Would be nice if the button text reflected the ramifications of the choices
* Does the "OK" button need to be greyed out until you've typed the string?

I think it would be really interesting to do two versions of this dialog via Finch: one with and one without the typing requirement. Anyone up for that? If the typing actually acts as a deterrent, that would be nice to know. If not, we should remove it. Also, you probably want to ask the user to type something that signifies that they accept the risk (e.g., type "allow scam" in the input field...OK, not really, but something that hints at the risk).
6.6 KB View Download
(a) Has this been rolled back yet?

(b) There is talk now of solving this problem (and others) by adding a new preference: Developer Mode. (For example, in Developer Mode we would not warn people about loading off-CWS/unpacked extensions.) pfeldman, are you up for implementing that or should we fish around for another implementer for that?

Comment 30 by Deleted ...@, May 3 2014

> (b) There is talk now of solving this problem (and others) by adding a new preference: Developer Mode.

Is the discussion of this happening in public, or is there somewhere I can read more?

Status: Fixed
Closing the original issue as fixed. I'm open to following up on this change with improved UX / wording, but as of now it is implemented as window.prompt in order to run the nested loop and be able to prevent default. If we are ready to sacrifice UX and drop the initial user action, we get more flexibility UI-wise.

@palmer: I am strongly opposed to the Developer Mode in any form - we have 'Inspect Element' in each context menu for a reason. Besides, 99% of DevTools customers are not aware of what CWS / unpacked extensions are, so I am not sure how it is relevant. Would be great to get into that discussion loop anyways - it is the first time I hear about it.

@felt: As for l10n, there has been decision made on the product owners level that DevTools as a whole is not localized. Besides, DevTools features are not going through the formal UI review process that is standard to Chrome.
#30: Sorry, it's in Google-internal email. pfeldman: I added you to the thread in which a broad base supported the idea of Developer Mode.

Basically it would just be a checkbox:

    [x] Yes, I want to use developer features

that would enable the Inspect Element menu item, unpacked extensions, and the Dev Tools Console. (Possibly other developer-y features.)

In the case that the user opens the Dev Tools Console without previously having turned on Developer Mode, we could present the checkbox there (kind of like how Firefox shows the "This might void your warranty!" warning the first time you go to about:config. Same could be done for the case where you haven't turned on Developer Mode and you want to run an unpacked extension.

Of course, we should also place the checkbox in the normal chrome://settings UI.
Owner: ----
Status: Available
As per request from felt@, I'm rolling it out.
Project Member

Comment 34 by, May 6 2014

The following revision refers to this bug:

r173365 | | 2014-05-06T07:37:16.223120Z

Changed paths:

DevTools: remove the 'always allow' self-xss dialog. It is likely to be replaced with the different first-run experience.


Review URL:
@32: FWIW, I am also opposed to the idea of Developer Mode.  I think it's antithetical to the goals of Chrome and the web and I think it's a poor attempt to split users into "expert" and "non-expert" populations, which isn't a generalization that actually makes sense for our userbase.  People have proposed using "developer mode" to control things like Omnitheatre, which is an especially bad idea and makes me extremely wary of any such thing.

Feel free to CC me on the relevant email threads.
Besides, a specific warning would be way more effective than a generic developer mode. A user being scammed into copying codes into their console probably would find it reasonable to tick a box saying "I am a developer". After all, they know that they are doing developer-y stuff by playing with code.

FWIW, the fix for Firefox[1] was just checked in.

 Issue 392737  has been merged into this issue.

Comment 38 Deleted

Comment 39 Deleted

Comment 40 Deleted

Comment 41 Deleted

Comment 42 Deleted


A new way to disable the developer console in Google Chrome has appeared, it overrides the method to throw an exception when explicitly working with "__commandLineAPI". The code can be found at the given URL.

This code effectively disables my developer console (Chrome 36.0.1985.125 m stable, Windows 8.1 x64).
Is it being used in the wild? I don't see much gain in disabling it if the method isn't being used -- there are many ways of getting around this due to the nature of JavaScript. The only true way of fixing this is to make the console execution not have any extra injected JS, or use browser-level APIs.
#43: Do you mind adding a comment to  bug 349993  or filing a new bug? 
No problem, I'll file it as a new bug.
The new issue about the console disabling code is here:
Thanks for reporting, berykubik. 
Over in  Issue 401535 , we've fixed the issue reported above.
 Issue 435149  has been merged into this issue.

Comment 50 by, May 18 2015

Labels: -Type-Bug -Pri-2 Type-Feature Pri-3
It looks like plans to do a Developer Mode have stalled, so maybe we should revisit something like this (but perhaps a lighter weight UI).

Some major websites show their own custom devtools warning to alert users, although it seems that Facebook recently stopped for an unknown reason.

Comment 51 by, May 18 2015

Facebook does not appear to have recently stopped -- this is a screenshot I took just now, from while logged in.
Screenshot from 2015-05-18 19:13:04.png
39.3 KB View Download

Comment 52 by, May 18 2015

Re #51: It looks like they are doing some kind of user profiling or an A/B test. I can't get it on my own account but I can see it in Incognito and on other people's tabs. Kinda neat.
There's a way to turn it off. You probably did that when you stumbled over it, but forgot it now? :D
There used to be one on

I don't see any now.
Could you not just build a system so a site could block the console anyways's just something as simple as a meta tag
<meta name="developer-tools" content="disabled" />
<meta name="developer-tools" content="inspector,console,network,..." />

If the meta tag is not there assume all permissions are allowed if the meta tag is there with disabled prevent the console as users should not be messing with HTML or JavaScript anyway. 

I don't understand why you would leave something so dangerous open for every idiot on the internet to abuse. as if someone ever found an exploit using JavaScript to install malicious software and chrome safe site prevented it someone could just start getting people to do it via the developer console to evade the safe site system.

I understand it's uses i use it daily myself but we sould have the abillity to prevent it without having to hack the console system. like Facebook and Netflix did
You don't want to restrict the ability to use the devtools, however, you will always need an escape hatch.

And then these pages explaining the self-xss attack will just explain how to go through the escape hatch. Unless you create a completely different "developer mode Chrome" that needs to be downloaded separately, that problem isn't going away.

Adding features to the browser to prevent such attacks is a better, more holistic solution, rather than relying on websites anyway.
Project Member

Comment 57 by, Jul 6 2016

Labels: Hotlist-OpenBugWithCL
A change has landed for this issue, but it's been open for over 6 months. Please review and close it if applicable. If this issue should remain open, remove the "Hotlist-OpenBugWithCL" label. If no action is taken, it will be archived in 30 days.

For more details visit - Your friendly Sheriffbot
The change was backed out, so we should remove this label, perhaps?

I can't remove it.
Status: Assigned (was: Available)
Components: -Security>UX
Labels: Team-Security-UX
Owner: ----
Status: Available (was: Assigned)

Comment 62 by, Oct 11 2017

@konkl, @8, re "serious"; the definition of "serious" is context-dependent. The issue here is that Chrome lets you put an invisible gun to your head with a simple Ctrl-Shift-J or a simple three-click combination. Noobs will forever be tricked into touching that box and once you touch it its game over. Curiousity is a dangerous beast, didn't you read Genesis? The forbidden fruit is called the Forbidden Fruit and yet its still eaten!

Comment 63 by, Oct 11 2017

@pkastin, @35, so what is one real use case where a non dev will need to use devtools?

Comment 64 by, Oct 11 2017

@paulir, @31, re " each context menu for a reason.."; and why exactly? Don't you think that we should actually make that a dev feature instead of a user feature?

Comment 65 by, Oct 11 2017

Actually there's a ridiculously simple solution to the conundrum. When Chrome is installed, developer tools is hidden. To unhide it, 2 steps are needed:

1. Go to <about:settings> and type in the Konami Code. This will show an option which reads <I want to be hacked by Javascript Code>.

2. Tick that option to enable developer tools.
As a data point, Safari puts developer tools behind a setting ("Show Develop menu in menu bar"). When this is disabled, none of the shortcuts to open dev tools work, and "Inspect element" is hidden from right click menu.
A non-dev use case: inspect-element to determine the classes and names of elements so I can write a user-side CSS rule to put into the Stylish extension; I do this myself from.

Another: when reporting bugs, I want to see if there's any JavaScript errors so I can include them in the bug report.

It seems to me that the problem isn't DevTools in general, but being able to use the Console to execute arbitrary JS in the context of the current webpage.  So how about this: instead of the doing the setting/warning thing for DevTools in general, just do it for executing JS from the Console.

Though a malicious actor might trick a user into editing an element to change that element's JS, so extend that default-off setting to also control if you can use DevTools to edit a page's HTML.  Editing HTML isn't something a non-dev is going to do (except for the purpose of faking screenshots).
Labels: Hotlist-EnamelAndFriendsFixIt
> Though a malicious actor might trick a user into editing an element to change that element's JS, so extend that default-off setting to also control if you can use DevTools to edit a page's HTML.  Editing HTML isn't something a non-dev is going to do (except for the purpose of faking screenshots).

This isn't necessarily a bad idea, but I wouldn't say that being able to edit some HTML to fake a screenshot necessarily implies having enough knowledge to avoid self-XSS.
c#69 I concur I think it might be best to implement something like Safari and put a warning or Developer option "if a website told you to do it submit it to ..." and provide a link for reporting a URL to safe-site, 

This also means chrome can then block ppl from seeing guides / sites telling users how to self-xss.
Chrome can't block sites with that content. Why block any number of domains
but let Facebook off the hook for their user generated content? That's a
cat and mouse game best left untouched. Which will also seem extremely
unfair and be easy to game.
Labels: -Hotlist-EnamelAndFriendsFixIt

Sign in to add a comment