How to prevent the risks of client-side caching

When a browser requests a page from a Web server it stores a copy of the files and images it receives in its cache -- a directory on the computer's hard drive. This is done to improve response times if the page is requested

    Requires Free Membership to View

again and to reduce network traffic. Unfortunately, this creates a security problem when a user requests sensitive files or information, such as account information or a management report, from your Web server. If the user is on a public computer in an Internet cafe for example, the sensitive data will remain on the computer after they leave. There are risks even if the user is located on your internal network. The sensitive data can be legitimately included in a nightly backup, thus leaking the data on to the backup tape. It is the Web developer's role to prevent the inadvertent release or retention of sensitive information.

Many Web developers assume that by adding the following Meta tag to a Web page it will be marked as un-cacheable and thus solve the problem of browsers storing sensitive documents:


Unfortunately, only a few browser caches and even fewer proxy caches take any notice of this Meta tag. However, HTTP 1.1 introduced a new class of HTTP headers -- cache-control response headers. By using these headers you can control how both browser caches and proxies handle Web

pages and ensure that sensitive documents are not cached. HTTP headers are generated and sent by the Web server before the actual HTML content of a page, and are only seen by the browser and any intermediate caches.

The two key cache-control response headers are:

  • NO-CACHE: This directive tells the browser that it has to request the document from the server for validation every time before releasing a cached copy.
  • NO-STORE: This directive instructs remote and local, shared and non-shared caches not to store a copy of the document under any conditions.

Note that no-cache does actually allow a copy of the document to be stored whereas no-store prohibits it. As you might expect, Internet Explorer (IE) and Mozilla browsers have different implementations of these cache-control directives.

Both browsers will cache a document requested over an HTTP connection that has the "no-cache" directive set. Mozilla will not cache any pages by default over an HTTPS connection, whereas Internet Explorer will, unless the user has enabled the "Do not save encrypted pages to disk" option. A Mozilla browser never stores documents set with the "no-store" directive, but Internet Explorer only fully follows this directive when the page is requested over an HTTPS connection. So the only way of ensuring that your sensitive documents and pages are not cached without requiring your users to manually set any IE options is to use the "no-store" directive over an HTTPS connection. All browsers supporting HTTP 1.1 will support this directive.

You can set the no-store response header in IIS by opening the HTTP Headers property sheet for a Web site or preferably for a folder within a Web site as it not a good idea to use this header globally across an entire Web site but purely for content that absolutely must not be cached on the client.

About the author
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book
IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for SearchSecurity's Web Security School and, as a SearchSecurity.com site expert, answers user questions on application and platform security.

This was first published in October 2005

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.