I've recently discover that if you use inspect element to see the source code of the Html, you can change this <input type="password"/> to <input type="text"/> then you can see the password revealed, So, how can I avoid that in angularJS? or pure Javascript?

Any dark in the light will be appreciated.

  • 34
    Can you please describe the attack you are trying to prevent? Are you worried that I will type in my password, then I will make the change you suggested so that other people can see my password? :D
    – TTT
    Commented Jan 28, 2016 at 17:01
  • 39
    Am I the only one that's confused by this question? Are we talking about the situation when a user enters a password, then someone physically attacks them and rips them off of their chair before they press enter, then fiddles with the page source so they can see the password that was entered in? I feel like I'm taking crazy pills!
    – TTT
    Commented Jan 28, 2016 at 17:21
  • 5
    @TTT This could be a scenario that takes place like in this question I just asked where a user types in their password then leaves for whatever reason leaving the typed password in the box.
    – DasBeasto
    Commented Jan 28, 2016 at 17:33
  • 6
    @DasBeasto - that is not something I would worry about. The user would have to type in their password, not press enter, leave their workstation unlocked, walk away, and this has to be on a shared computer or in a public setting. If you're worried about that, you should also worry that the user will write their password on a piece of paper and leave it next to the keyboard, and you should be much more concerned about someone installing a keylogger on the machine.
    – TTT
    Commented Jan 28, 2016 at 17:40
  • 17
    This is basically a case of 'if an attacker has access to your machine, its not your machine anymore'. Similar statements are true even on the server side. Commented Jan 28, 2016 at 17:48

8 Answers 8


This sounds like a bad case of Security Theater

Security theater is the practice of investing in countermeasures intended to provide the feeling of improved security while doing little or nothing to actually achieve it.

I say this because in all reality...

Given enough time, effort, and computing power security is nothing more than a delay.

Of course it gets worse than that. Javascript is an computer based language, which means it must be run by a machine. That machine can be told to ignore your Javascript.

What this really means though is that you're asking the wrong question. What you're really asking:

How do you keep your forms safe from someone using saved passwords to fill out the form, and then changing the type of the form to read it?

And to this answer it's pretty simple:
Keep your terminal safe and secure. The only way to prevent this kind of attack is to not let an attacker on a system with a saved password in the first place.

Why? Because you have a "spectrum". Let's call it the security spectrum in this simplified example:
At the basis of simple security you have the following:

Security >----------------------------------------------< Ease of Use

In most cases this is what happens:
The more Security you have, the less Ease of Use you have.
The more Ease of Use you have, the less Security you have.

By using a form that has a password in it and leaving it there, you are increasing your Ease of Use and decreasing your Security

  • 18
    Pedantry: it's not just a spectrum. Some people decrease ease of use without doing anything to increase security. In other cases, you can increase security without decreasing ease of use. Commented Jan 28, 2016 at 18:39
  • 3
    Javascript being interpreted has nothing to do with the problem. Even if it were compiled (which it frequently is), the browser could still ignore and not run it. Commented Jan 28, 2016 at 18:47
  • 3
    @Michael this was a simplified example, so I'll clarify that. Commented Jan 28, 2016 at 19:37
  • Now I am wondering what is the point of asking for system password when opening Chrome's manage password. Attacker can easily know the password from the auto-populated fields. Only benefit is he won't be able to list down the saved passwords at one go.
    – aaa
    Commented Jan 29, 2016 at 0:44
  • @aaa that is kind of the idea. If you have left your information in an area where someone can get access to the debugger you have used your computer in an unsafe location in a bad way, which is already a breach of security Commented Apr 4, 2016 at 20:20

There is no way to prevent an attacker doing this if they are already accessing the developer tools - they can simply pause the javascript and continue what they are doing. The best you may be able to do is clear the password box after a small amount of inactivity.

  • 2
    Note that clearing the password field with Javascript may not work against CTRL+Z. Commented Jan 28, 2016 at 16:59
  • 12
    No way to prevent an attacker from doing what exactly? Looking at their own password?
    – TTT
    Commented Jan 28, 2016 at 17:17
  • 1
    I assumed he is worrying about people leaving their login details on the screen while they make a Coffee, and an attacker using the vector he described to see it
    – Will
    Commented Jan 28, 2016 at 18:26
  • @WilliamDunne - yep. I probably could have deleted my comment here after we clarified it up above.
    – TTT
    Commented Jan 28, 2016 at 18:52
  • I'll add to thiscomment that if i have access to developer tool i can see every request sent by the browser with their data non-encrypted (even if HTTPS) so i'll be able to see the password there too.
    – Walfrat
    Commented Jan 29, 2016 at 11:07

The bottom line is that you can't, but this is not as much of an issue as one might think.

The thing to keep in mind is that when you change the source in a browser's debugger (which is what you're describing), it doesn't get saved anywhere. This means that the change only affects the machine the debugger is running on. I can't change the password field to 'text' on everyone's machine, just mine. It also means that the change only takes effect until the next time the page is loaded, so even if I set it up once, I can't turn a machine into a password-collecting robot by doing this.

Another thing to keep in mind is that scripts don't have to change the password field's type to get at its value. They can get it through plain old scripting, and there are very real advantages to doing it that way. The biggest is that since you don't change the field's type, the user doesn't see anything unusual, so users aren't tipped off that something could be wrong.

Now, all of this said, you do have to be wary of cross-site scripting attacks, which can do the sorts of things you mention (though they still don't have to change the field's type to get its value). There are already a number of best practices to avoid XSS attacks, and the common XSS filter evasion methods are well known, so you can test against them too. None of these will stop the debugger trick, but as I outlined above, the debugger trick doesn't need to be stopped: XSS does.

The bottom line is that you don't need to be alarmed about the browser debugger. There are related attacks that you should be worried about, but they're well-studied, and none of them involve the browser debugger.


You can't. The form needs to be able to send the password to the server for validation. Even if you develop some kind of obfuscation technique (not recommended) then, like William Dunne said, you can simply pause/stop Javascript.

You are trying to achieve security through obscurity, and it won't work.

  • You assume that every people that can right click and inspect an input element and change its type from password to text are cappable of debuging javascript using proper breakpoints and event listener hooks? I believe such an assumption is far from reality. Commented Jun 7, 2021 at 8:17

You can not do this because all things are happening on the client side and he has almost full access to your code (html, css, javascript) using developer tools. So, he can pause or stop javascript.


If you're really worried about this, you could do away with passwords entirely in your application. Have the user enter their username or email and send them an email with a temporary login link.

  • If someone has access to scrape password data from your forms, they likely have access to your cookies too: Once someone clicks the temporary login link, they could steal your session cookie and use that to login instead.
    – Rohaq
    Commented Jan 29, 2016 at 15:38
  • Sure, but the user may not be logged into their email on the same computer and it prevents the potential to expose a password which the user may use on other sites. If someone has access to your email they can already easily reset your password on most sites. In reality, the whole scenario is a bit ridiculous and there's not much you can do as a developer, as other answers have stated.
    – Sam
    Commented Jan 29, 2016 at 15:47

You might be able to use divs and other elements to make your own text field, kinda like the text fields on google forms. If you did this, you could set it up so that as the user types, it just modifies the content of a encrypted JavaScript variable, and does not actually type in the text field.


In Javascript, for already saved passwords, a way could be:

on load:

  1. save the value of the input in a variable
  2. replace the value the input with a random sting with the same length

on login click:

  1. replace the random value with the value that you saved in the variabe
  2. submit the form

Remeber that:

Someone can anyway read the password from the variable through javascript
for example:
console.log( passwordVAR );

  • 8
    This is theatrics and obfustication, not security. This will reduce security for users, not increase it.
    – Caleb
    Commented Jan 28, 2016 at 22:20
  • @Caleb I know it's been a while since this Q/A, but I'd like to know how a method like this can reduce security; can you please provide a brief explanation on why an obfustication like this reduces security? Commented Jun 7, 2021 at 8:11
  • @ChristosLytras First, it introduces more attack surface. If you are coding things up this way clearly you don't understand what you are messing with, so any code you write is going to add exposure, not reduce it. Second you loose some of the browser's built in security measures. Third you create an illusion of security without the real thing: like a smoke screen used to deflect cannon fire. The canon will still blow you to pieces if you aren't in the trench or behind a real barricade, but because you can't see it pointed at you you feel safer standing up and walking around.
    – Caleb
    Commented Jun 10, 2021 at 8:35
  • @Caleb thank you for your reply. IMO all of your points are valid for developers and/or hackers that know how to debug an application and dive deep into memory state (from OS debugging with ASM, to browsers debugging with debug console), but not everybody that knows how to change an input field type from password to text has the knowledge to debug an application. The hacker will have the password either way by digging into the state variables but not everybody is a hacker. Anyway, I would like to have an extended discussion regarding this subject but we can't do it here. Thanks again. Commented Jun 10, 2021 at 10:15
  • @ChristosLytras The panel that shows Javascript values is literally right in the same place one would need to go to fiddle with the page source, and in some browsers it is better organized; and again you would be side stepping the default browser protections it uses to mitigate risks posed by password fields. Frankly, I'm not interested in having an extended discussion having to defend why obscurity and theatrics is bad security—the topic is covered at length in many places.
    – Caleb
    Commented Jun 10, 2021 at 16:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .