A problem arises when this feature is activated on a computer that more than one person uses, such as one in an Internet cafe. The browser will then automatically complete a form with the data of a previous user. You can prevent most browsers from storing data entered in certain input fields by adding the AutoComplete attribute and setting it to off. Some sites also randomize the name of key fields, such as the password field, so the...
AutoComplete feature doesn't recognize it as a field and doesn't expose previously entered data.
It's interesting to note that even with the possible security concerns, and the fact that AutoComplete isn't officially a World Wide Web Consortium (W3C) standard yet, it's currently being considered to be part of the Web Forms 2.0 specification. Additionally, many banking institutions use the AutoComplete attribute and do not allow browsers that don't support it to access their sites.
Another Web site form security issue can occur when sensitive data received from a user is redisplayed. A browser will store a copy of a page in its cache, in a directory on the computer's hard drive. This is done to improve response times and reduce network traffic if the page is requested again. Unfortunately, sensitive data can remain on the computer and could even be legitimately included in a nightly backup, thus leaking the data onto the backup tape.
To prevent the caching of sensitive Web pages, HTTP 1.1 introduced a new class of HTTP headers called Cache-Control response headers. Using these headers can control how browser caches and proxies will handle your Web pages, ensuring sensitive documents are not cached. HTTP headers are generated and sent by the Web server before the actual HTML content of a page. They are only seen by the browser and any intermediate caches. As you might expect, Internet Explorer (IE) and Mozilla browsers have different implementations of these cache control directives. The only way to automatically ensure sensitive documents and pages are not cached is to use the "no-store" directive over an HTTPS connection.
Therefore, adding a Web server certificate was a good idea. You can set the no-store response header in Internet Information Server (IIS) by opening the HTTP Headers property sheet for a Web site, or preferably a folder within a Web site. While it is not a good idea to use this header globally across an entire Web site, it should be used for content that absolutely must not be cached on the client.
Dig Deeper on Web Browser Security
Related Q&A from Michael Cobb
A new programming language called Wyvern is helping developers use multiple languages in one app securely. Application security expert Michael Cobb ...continue reading
Gartner predicts more than half of all mobile apps will use HTML5 by 2016, but what threats will this cause the enterprise? Expert Michael Cobb ...continue reading
Public key pinning aims to reduce the lack of trust associated with digital certificates and certificate authorities. Expert Michael Cobb explains ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.