Take control of Cache-Control and local caching

TL;DR

• Caching speeds up website content delivery
• What caching directives are and how to use them
• The No-cache directive does not prevent caching
• The No-store directive prevents caching

Introduction

The HTTP Cache-Control header is sometimes misunderstood. It’s important because it is used to specify caching mechanisms within requests and responses. In its typical format, it reveals details as to how resources are stored, the location of the resource and the maximum age before expiring.

What is browser caching?

Browser caching is a function that allows web browsers to store copies of a variety of web resources locally. This is intended to increase the speed and efficiency at which a website loads its contents and returns to the user. This has positive outcomes such as reducing load times, bandwidth usage, and server requests.

As an example, on first visiting a website, the browser may store content such as the logo, scripts or other images. When revisiting the page, it will load much faster as it does not have to reload this content from the server.

This is where the Cache-Control header comes in. It tells the browser what do with caching, including:

• If the resource can be cached
• How long it should be cached for
• Whether it needs revalidation before use
• Where it can be cached

Typical caching behaviour directives

No-store: This directive prevents any caching of the response by the browser of intermediary caches, it would be typical for sensitive data such as user tokens to use this directive.

No-cache: The response can be stored, but the cache must revalidate with the server before returning it.

Public: Can be cached by any cache, even shared caches.

Private: Only cached by the browser.

Max-age: The number of seconds until the cache’s content expires.

Must-revalidate: Once the content has expired, revalidation with the server must happen to reuse.

Misconceptions

Despite its name, the No-cache  directive does not prevent caching. It tells the browser that content can be cached, but to validate content with the server before reusing it – which is typically done with an ETag or Last-Modified header.

The no-store directive is the only directive that ensures that no content is stored locally. If handling sensitive information such as user keys, the use of this directive would be imperative.

Examples of use

Can be used for non-sensitive content. This could be static assets such as images or JavaScript files which do not change frequently:

Cache-Control: public, max-age=86400, must-revalidate

Can be cached publicly by browsers and intermediate caches with a time of 86400 seconds (24 hours) until the cache expires and must be revalidated with the server again.

User-specific content that isn’t sensitive but still needs to be cached. This could be content like user dashboards or account settings pages, typically done with performance and user presentation in mind:

Cache-Control: private, max-age=3600, must-revalidate

Can be cached privately by a user’s browser only 3600 seconds (1 hour) until the cache expires and must be revalidated with the server again.

Content that contains sensitive information such as authentications tokens, API keys or banking information for example:

Cache-Control: no-store

Does not store anything!

Deciding on directives

When it comes to deciding on which directives to use when implementing the Cache-Control header, we now know that there is only one certain answer and that’s when it comes to any sensitive content, that, if obtained, could lead to a malicious actor being able to compromise the confidentiality or integrity of company data. Any weakness found where sensitive information is stored locally can be a hacker’s golden ticket!

So, when it comes to any sensitive content that could lead to an attacker being able to compromise the confidentiality or integrity of company data, there’s only one directive choice:

It is important to consider the implications and benefits as well as security:

• Faster load times increase usability for customers, increasing their satisfaction and likeliness to use the service again.
• There is less load on the server and reduced bandwidth usage.
• Some applications can use cache content to work offline. This might be ideal in a mobile application for example where it can still be used without mobile signal.

Conclusion

Could the content lead to company or user disruption if it falls into the wrong hands? Use No-store.

Is the content user specific but will not lead to compromise in the event it’s obtained? Private cache with revalidation that occurs after a short time.

Is the content generic and non-sensitive? Public cache with revalidation that occurs after a longer time.