Cache keys for image CDN signed URLs

Why signed URLs miss the cache

A CDN identifies a cached object by its cache key, and by default that key is built from the request URL including its query string. Signed URLs deliberately add a unique, expiring set of signature parameters to the query string, which is exactly what makes them secure: each link is different, time-bound, and only issued to someone with the right credentials. But that uniqueness is also the problem. When every request for the same underlying object carries a different token, the CDN effectively sees a new URL each time, so cf-cache-status returns MISS on every request, the object is never reused, and you lose the caching benefit you signed up for.

This is a common report for origin image stores such as S3 or Cloudflare R2, where a Worker signs a GetObject request to a private bucket and serves it on the edge. The private bucket is entirely reasonable, but the signed URL that authorises it, with its per-request signature query parameters, defeats default caching for the images.

Excluding signature parameters

The fix is to customise the cache key so the signature parameters are excluded and the key is based on the object path rather than the temporary token. In Cloudflare, do this on the Cache Rules page:

1. Create a rule and set the match expression (for example, the path or hostname serving the images).
2. Under Cache eligibility, select Eligible for cache.
3. Add the Cache Key setting and, in the Query String section, choose the option to ignore specific parameters.
4. List the signature parameters to drop, typically X-Amz-Signature, X-Amz-Credential, X-Amz-Date, X-Amz-Expires, X-Amz-SignedHeaders, and X-Amz-Algorithm.
5. Deploy the rule.

Because the key no longer includes the volatile values, every valid visitor's request resolves to the same cached entry for that object path, so first request populates the cache and later ones hit. Note that credentials still work: the signature stays in the URL for the origin to validate, but it is simply not part of the object key the CDN uses to de-duplicate responses.

Safely caching private images

Excluding the token from the cache key changes the security model, so think it through before applying it broadly. Once an image is cached under a token-independent key, one visitor who is allowed to fetch it populates an object that any other request for that path, authenticated or not, can then be served from the edge. That is fine for weakly protected assets where you only wanted to stop casual deep-linking, but it is not a substitute for real access control on a genuinely private asset.

For genuinely sensitive content, keep the URL guidelines happy but do not cache it publicly: you can serve signed private images network-only, or use a rule that excludes tokens on a per-path basis only for the assets you are sure can be shared from the edge. When you do cache, reason about the key the way the CDN cache guide and cache reserve for HTML describe, and set an appropriate TTL via the controls in browser cache TTL so stale variants expire. The general rule: signed URLs and CDN caching can coexist, but only when you deliberately separate the authorization token (kept in the request) from the cache identifier (kept to the stable object path).