Cacheable Https Response

Title:

Cacheable HTTPS response, If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer in future.

Vulnerability:

What is cacheable HTTPS?
Caching is an entirely OPTIONAL feature of HTTP, it can be assumed that reusing a cached response is desirable and that such reuse is the default behavior when no requirement or local configuration prevents it. The goal of caching in HTTP is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases.
By default web browsers should cache content over HTTPS the same as over HTTP, unless explicitly told otherwise via the HTTP Headers received.
The most common form of cache entry is a successful result of a retrieval request: i.e., a 200 (OK) response to a GET request, which contains a representation of the resource identified by the request target. However, it is also possible to cache permanent redirects, negative results (e.g., 404 (Not Found)), incomplete results (e.g., 206 (Partial Content)), and responses to methods other than GET if the method's definition allows such caching.

If the application is storing responses for many requests having sensitive data in local cache for longer period of time then data loss and confidentiality beach of data incidents are possible to happen. In certain cases by using sensitive data from cache it is possible for user to perform many other session vulnerabilities namely privilege escalation (horizontal and/or vertical).

Verification of vulnerability:

By default web browsers should cache content over HTTPS the same as over HTTP, unless explicitly told otherwise via the HTTP Headers received.
 This can be verified by checking for presence of this header (either in request or response) max-age value in the ?Cache-Control? header to a non-zero value, e.g.
Cache-Control: max-age=3600
will tell the browser that this page can be cached for 3600 seconds (1 hour)

Solution:

The web server should return the following HTTP headers in all responses containing sensitive content:
Cache-control: no-store
Pragma: no-cache

Standard Cache-Control directives that can be used by the client in an HTTP request:
Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: only-if-cached

Standard Cache-Control directives that can be used by the server in an HTTP response:
Cache-Control: must-revalidate
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: public
Cache-Control: private
Cache-Control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-Control: s-maxage=<seconds>

*Extension ?Cache-Control? directives are not part of the core HTTP caching standards document. Be sure to check the compatibility table for their support.