Caching security
Information that is protected by access control and is therefore restricted to a limited set of people needs special consideration when served from an access control agnostic cache. These considerations especially apply to server side caches but you also need to consider local browser caches.
Browser caches usually have no issues unless the computers are shared between multiple users with different levels of access. If you access WebSphere Portal from a shared computer, it is important to realize that all users who have access to the computer can access content that is cached in the local browser cache. To prevent this from happening, do not enable public or private caching of the content. Caching is disabled by default.
Depending on the type of browser you are using, you can still experience information leakage from shared computers, even if content is completely disabled, because some browsers serve content that is accessed by clicking the browser's Back button from a separate history cache that is not affected by HTTP caching directives. As a result, if you click the Back button, you may see content generated from the previous user even if the previous user performed a logout. To prevent this from happening, the markup that is rendered on logout should explicitly clear the browser's history cache, which typically requires browser-specific script coding, or display a message to close all browser windows after logout. History cache can typically be disabled in the browser but it may be activated by default.
The WebSphere Portal and Lotus Web Content Management 6.1.x Performance Tuning Guide provides information about caches for WebSphere Portal and Web Content Management. After you have setup your environment, review the tuning guide to learn more about stand-alone and cluster tuning and then read about both WebSphere Portal and Web Content Management caches.
Lotus Web Content Management Caches