Agent Guides › Web Agent Guide › Protecting Web Applications › Control How HTTP Header Resources are Cached › Security Issues Related to Caching HTTP Header Resources

Security Issues Related to Caching HTTP Header Resources

The setting of the AllowCacheHeaders parameter may have security implications.

The setting are as follows:

• Yes—setting AllowCacheHeaders to yes introduces security issues. Pages which are personalized by an application on the web server but do not have the appropriate cache control headers set may become cached in the browser or any HTTP intermediary. This can introduce unexpected behavior and allow a browser to save sensitive data to the disk.

  Additionally, setting this parameter to yes prevents the Web Agent from enforcing session timeouts across all resources. If a resource is served from browser cache, the Agent has no chance to get the SMSESSION cookie and validate the session. Therefore, be sure to evaluate your session security needs before enabling this setting.

• No—the default. If you choose this option, the Web Agent removes the cache-related headers from requests for protected resources. The web server now treats the request as an unconditional request, and will not perform any cache validation operations.

  Note: If you are configuring the LogOffURI parameter, we recommend accepting no as the default value. Otherwise, the browser will deliver a cached version of the LogOffURI resource and the user session will not be terminated.

• None—if you set AllowCacheHeaders to none, the Web Agent tells the web server to remove all cache-related headers for protected and unprotected resources.

If the session has been terminated, the browser will not use what is in cache, regardless of this setting.

Note: See RFC 2616, Section 13 "Caching in HTTP" for more information about HTTP/1.1 caching mechanisms."