Skip to content

Preventing browser caching

If there are dynamic pages in your application, which also include sensitive information, you need to prevent caching. This can be done by making sure that the applications return the following HTTP security headers in HTTP responses.

Cache-Control:no-store, no-cache, must-revalidate

The following topics explain how you can configure these security headers for different types of applications used in WSO2 Identity Server.

Preventing for Management Console

You can enable these headers for the management console by adding the following configuration to the web.xml file (stored in the /repository/conf/tomcat/carbon/WEB-INF/ directory).


Preventing for web applications

If your web application (stored in the /repository/deployment/server/webapps/ directory) serves dynamic pages/content, then make sure that either URLBasedCachePreventionFilter or ContentTypeBasedCachePreventionFilter is available in the web.xml file of the particular application.

Note that the applications that are included in the /webapps directory by default in a WSO2 product do not serve sensitive content that requires cache prevention. However, if you are adding any new applications, you need to be mindful of this requirement.

Preventing for Jaggery applications

For Jaggery-based applications (stored in the <IS_HOME>/repository/deployment/server/jaggeryapps/ directory), either URLBasedCachePreventionFilter or ContentTypeBasedCachePreventionFilter should be available in the jaggery.conf file as shown below.

"filters": [{"name": "ContentTypeBasedCachePreventionFilter","class": "org.wso2.carbon.ui.filters.cache.ContentTypeBasedCachePreventionFilter","params": [{"name":"patterns","value":"text/html\",application/json\",plain/text"},{"name" : "filterAction","value":"enforce"}, {"name":"httpHeaders","value": "Cache-Control: no-store, no-cache, must-revalidate, private"}]