The "Cache-Control" header is probably overdone in this example, but should cover various implementations.Ī nice tool to test this is ratproxy, which will identify inconsistent cache headers. In summary, a safe set of HTTP response headers may look like:Ĭache-Control: private, no-cache, no-store, max-age=0, no-transform For out discussion, this doesn't really matter because we never want the request or response to be cached so it is best to have no Vary header. You may decide to deliver the same content independent of the user agent, and as a result, "Vary: User-Agent" would help the proxy to identify that you don't care about the user agent. The request consist not just of the URL requested, but also other headers like for example the User-Agent field. A Cache will index all stored responses based on the content of the request. The "vary" header is used to ignore certain header fields in requests. "Pragma: no-cache" is equivalent to "Cache-Control: no-cache". Thie is an older header, and has been replaced by the "Cache-Control" header. I am not aware of a way to randomize the Etag. A nice way to come up with an Etag would be to just send a random number, or not to send it at all. In some cases the ETag is derived from information like file inode numbers that some administrators don't like to share. The Etag can be understood as a serial number to provide a more granular identifcation of stale content. The ETag will not prevent caching, but will indicate if content changed. A expiration time in the past, or just the value "0" will work to prevent caching. Modern browsers tend to rely less on the Expires header. Setting it to "0" will prevent caching.Ĭache-Control: private, no-cache, no-store, max-age=0 Only if you rely on digital signatures transmitted to verify an image for example).The "max-age" option can be used to indicate how long a response can be cached. "no-transform" will prevent that (but again: doesn't matter for SSL. This could break digital signatures in some cases. Some mobile providers will compress or alter content, in particular images, to save bandwidth when re-transmitting content over cellular networks. The "no-transform" option may be important for mobile users. A better option to add is "no-store" which will prevent request and response from being stored by the cache. For example the "no-cache" option just implies that the proxy should verify each time the page is requested if the page is still valid, but it may still store the page. Other options are sometimes used inappropriately. A proxy will not cache a page if it is marked as "private". Most importantly, the page can be marked as "private" or "public". There are a number of options associated with this header. This is probably the most important header when it comes to security. The server needs to include appropriate headers to indicate if the response may be cached. It is the goal of properly configured caching headers to avoid having personalized information stored in proxies. However, HTTPS inspecting proxies are available and common in some corporate environment so this *may* apply to them, even though I hope they do not cache HTTPS content. The browser does not typically cache HTTPS content, and proxies will not inspect it. I think this is a good reason to talk a bit about caching in web applications and why it is important for security.įirst off all: If your application is https only, this may not apply to you. The headers allowed authenticated content to be cached, which may lead to sessions being shared between users using the same proxy server. Earlier this week, an update for Media-Wiki fixed a bug in how it used caching headers.
0 Comments
Leave a Reply. |