Learning notes: How to prevent web apps from storing sensitive data

In some cases, the custom web App saves sensitive (proprietary) data to the user's cache folder. If you do not re-architect the app, does the logoff script using Sysinternals SDelete ensure that the data is completely deleted and that there are no recoverable residues?
Michael cobb:secure Delete or sdelete is a Windows command-line user program that can be used to safely delete file data for existing files and unallocated portions of the disk. However, you cannot use it to clear data from remote user devices, and your web app's dismiss script will not be granted permission to run this powerful tool, which is a completely wrong tool for Web app data protection. There is also a more efficient way to ensure that sensitive data is not kept in the user's cache folder.

The browser saves page resources for two purposes: history and caching. The history feature allows users to quickly return to previously browsed pages, while caching is used to improve performance. Downloaded content, such as a logo or blog post, is stored in a cache folder on the user's device so that each time the user views the content, it does not have to be downloaded repeatedly. Content stored for caching or historical purposes can then be viewed by viewing the browser's cache or simply by pressing the browser's Back button. This may put sensitive data such as credit card information and user names at risk.

To avoid this privacy threat, there is no need to redesign the application by leveraging digital certificates and some additional cache control header domains in each Web page to solve the problem of caching information. A Web server certificate is installed first and all content is provided over HTTPS, which provides confidentiality for the data transferred between the app and the user. Because browsers have different default behaviors to cache HTTPS content, pages that contain sensitive information should include the cache Control header field to ensure that the content is not cached. To cover the various browser versions, the complete header field that avoids the content being cached should be:

Specific as follows:

• Cache Control "No-store" will prevent requests and responses from being cached

• Add "Private" to place the Proxy Server cache page

• "Back" button will no longer display sensitive data by setting "Must-re-validate"

• The "max-age" option indicates when the response was cached and set it to "0" to prevent caching

Today's browsers tend to be less dependent on the "Expires" header domain, but to ensure security, the enterprise should set the expiration time to "0" to prevent older browsers from caching. In order to be compatible with http/1.0, the response should also include the "Pragma:no-cache" header domain. "No-transform" is important for mobile users, as some mobile operators compress or modify content to conserve bandwidth.

After these changes are deployed, the developer should test that the app no longer leaks sensitive data into the browser cache. A manual search of the cache folder for each major browser ensures that sensitive data is not stored. If data is found, use a proxy server such as WebScarab to check the response of the server and examine each page that contains sensitive information. In these pages, make sure that the server is sending the correct response header field and that the browser does not cache any data. AC Q2881064156

Learning notes: How to prevent web apps from storing sensitive data