7. Security Considerations

This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP caching. More general security considerations are addressed in "HTTP/1.1" (Section 11 of [HTTP/1.1]) and "HTTP Semantics" (Section 17 of [HTTP]).

Caches expose an additional attack surface because the contents of the cache represent an attractive target for malicious exploitation. Because cache contents persist across HTTP requests, attacks on a cache can reveal information long after a user believes that the information has been removed from the network. Therefore, cache contents need to be protected as sensitive information.

In particular, because private caches are restricted to a single user, they can be used to reconstruct a user's activity. It is therefore important that user agents give the end-user control over them, for example, allowing them to delete stored responses for some or all origin servers.

7.1 Cache Poisoning

Storing malicious content in a cache can magnify the reach of an attacker to affect multiple users. This "Cache Poisoning" attack occurs when an attacker uses implementation flaws, elevated privilege, or other techniques to insert a response into a cache. This is especially effective when a shared cache is used to distribute malicious content to many clients.

One common vector for cache poisoning attacks is to exploit differences in message parsing between proxies and user agents; see Section 6.3 of [HTTP/1.1] for the relevant requirements.

7.2 Timing Attacks

Because one of the primary uses of a cache is to optimize performance, its use can "leak" information about which resources were previously requested.

For example, if a user visits a site and their browser caches some of its responses, then navigates to a second site, that site can attempt to load responses it knows exist on the first site. If they load quickly, it can be assumed that the user has visited that site, or even a specific page on it.

This "Timing Attacks" can be mitigated by adding more information to the cache key (for example, the identity of the referring site, to prevent the attack described above). This is sometimes called "Double Keying".

7.3 Caching of Sensitive Information

Implementation and deployment flaws (often due to a misunderstanding of cache operation) can result in sensitive information (such as authentication credentials) being cached, thereby exposing it to unauthorized parties.

Note that the Set-Cookie response header field [COOKIE] does not inhibit caching; a cacheable response with a Set-Cookie header field can be (and often is) used to satisfy subsequent requests to the cache. Servers who wish to control caching of these responses are encouraged to emit appropriate Cache-Control response header fields.