Can setting a cache-control header improve application data security?

We have a custom Web application that in some instances saves sensitive (proprietary) data in users' cache folders. Without re-architecting the application, would a logoff script using Sysinternals SDelete be the best way to ensure that data is completely deleted with no recoverable artifacts?

Secure Delete or SDelete is a Windows command-line utility that can be used to securely delete existing files as well as file data that exists in the unallocated portions of a disk. However, this is not something that you can use to clear data on your remote users' devices; a logoff script fired by your Web application would not be granted the permission to run such a powerful tool, and it is completely the wrong approach to Web application data security. There are more effective ways to ensure sensitive data is not left in a user's cache folder.

Browsers store page resources for two purposes: history and caching. The history function allows users to quickly return to a previously viewed page while caching is used to improve performance. Downloaded content (such as a logo or blog post) is stored in a cache folder on a user's device so that it doesn't have to be repeatedly downloaded each time the user views that content. Any content stored for the purposes of caching or history can be viewed at a later time by examining the browser's cache or by simply pressing the browser's "Back" button. This can potentially put sensitive data such as credit card details and usernames at risk.

To avoid this privacy threat, there is no need to redesign the application, as just a digital certificate and a few extra cache-control headers in each webpage can resolve the problem of cached information. First install a Web server certificate and deliver all content over HTTPS; this will provide confidentiality for data in transit between the application and its users. As browsers have different default behavior for caching HTTPS content, pages containing sensitive information should include a cache-control header to ensure that the contents are not cached. To cover various browser implementations the full set of headers to prevent content being cached should be:

Cache-Control: no-cache, no-store, private, must-revalidate, max-age=0, no-transform

Pragma: no-cache

Expires: 0

To explain:

• The cache-control "no-store" option will prevent the request and response from being stored by the cache.
• Adding the "private" option will prevent proxies from caching the page.
• The "Back" button can be stopped from showing sensitive data by setting the option "must-re-validate."
• The "max-age" option indicates how long a response can be cached and setting it to "0" will prevent caching.

Modern browsers tend to rely less on the "Expires" header, but for consistency organizations should set the expiration time to "0" to prevent caching by older browsers. To remain compatible with HTTP/1.0, the response should also include the "Pragma: no-cache" header. The "no-transform" option is important for mobile users, as some mobile providers compress or alter content to save bandwidth.

Once these changes have been implemented, developers should test that the application no longer leaks sensitive data into the browser cache. A manual search in the cache folder of each of the major browsers should confirm that no sensitive data has been stored. If data is found, use a proxy such as WebScarab to review the server's responses and check every page that contains sensitive information. On these pages, be sure the server is sending the correct response headers and instructing the browser not to cache any data.

Ask the Expert!
Want to ask Michael Cobb a question about application security? Submit your question now via email! (All questions are anonymous.)