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 reported 43% of Microsoft XML users are running vulnerable versions of the software. Security expert Michael Cobb discusses how to mitigate the ...continue reading
Security expert Michael Cobb explains what Open Authorization or OAuth 2.0 is, its pros and cons, and how it is different from bring your own ...continue reading
While the fundamentals of securing an e-commerce website haven't changed in a few years, there are new threat vectors and security risks to be aware ...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.