Caching With Query Strings – A Good Idea?

Caching software allows you to configure your cache such that each time you use a query string, a separate cache is created for it. So you’ll have different caches for the following:

style.css?v=1
style.css?v=2
etc…

Personally, I set my cache configuration to “Ignore query strings” because it turns out to be much more efficient, and there are plenty of opportunities for abuse. Let’s look at some instances where you might want to turn this on.

Cloudflare’s “Standard” Caches Query Strings

If you’re using Cloudflare, you’ll notice that there are three query string options:

1. No query strings
2. Ignore query string
3. Standard

The first option will only serve a file from cache if there is no query string. The “Standard”, which is on by default, creates a separate cache for each query string. I suggest changing this to “Ignore query string” for the reasons given below.

Enumeration Attacks are Made Easy

I’d written earlier about how enumeration attacks are dangerous because the attacker can request a new URL by simply incrementing a counter with very little effort into finding out whether the new URL is valid. Allowing your server to store a separate cache for each query string makes this process much easier for an attacker. They can essentially request the same page or resource an infinite number of times, and your server will be forced to generate it over and over, causing an infinite workload.

This kind of thing makes DDoS attacks against your site very easy.

Beware of Web Cache Poisoning

Web cache poisoning is a dangerous attack where an attacker manages to compromise the cache by forcing the server to generate an undesirable page, thereby placing that page into the server’s cache. As a consequence, that page will then be served to everyone who requests it from then on out. It’s a particularly insidious attack, that might be very difficult to diagnose.

Once for example, a certain page on my site was temporarily down and got redirected to the home page, which then got cached. So from then on, the cached version (my home page) was served every time someone visited the original page. I had a terrible time debugging this, and it made me acutely aware of how vulnerable we all are to even accidental web cache poisoning.

Serving Different Pages Based on the Query String

All that said, there are plenty of legitimate uses for query strings, especially for dynamic websites. Even for non-dynamic ones, you might serve different versions of your site depending on the query string. For example, a different language. Normally, Cloudflare only caches static files, so this wouldn’t normally be a problem. But if you use the “cache everything” solution, it could get very tricky to handle.

Dynamic Sites Can’t Have Too Much Caching

It’s a constant battle between performance and customization. If your site sells stuff with a shopping cart etc, then you simply can’t afford to cache too much HTML. Your site needs to be dynamic to reflect changing numbers, prices, and even personalized content if your customers are signed in. However, if you have a relatively static site, then you can go all out and cache everything from JavaScript to pure HTML.

Dynamic sites should stick to only caching static assets like JS, CSS, images, and fonts. It’s simply too risky to do anything else. But for these static assets, it should be perfectly safe to turn off query string parameter caching. Otherwise, a malicious attacker can actually sabotage your future updates by priming later versions with the old files in advance and you’ll have no idea why your site isn’t working!