Private Storage signed URLs revalidate instead of hitting Smart CDN cache

[matiasvillaverde]

Hi Supabase team. I am trying to understand whether this is expected behavior or a Smart CDN issue.

I am serving images from a private Storage bucket with signed URLs. The same exact signed URL is reused across requests. Based on the Smart CDN docs, I expected the first request for that signed URL to be a MISS, and later requests for the same exact URL/token to become HITs.

What I see instead is:

GET 1: cf-cache-status: MISS
GET 2: cf-cache-status: REVALIDATED
GET 3: cf-cache-status: REVALIDATED
GET 4: cf-cache-status: REVALIDATED

The important detail is that I am not generating a new signed URL each time. It is the same URL, same token, same object.

I also tried uploading the object with a very aggressive cache control value:

Cache-Control: public, s-maxage=31536000, max-age=31536000, immutable

The object metadata stores that value correctly, but the signed private URL still revalidates on every request. A HEAD request to the signed URL returns cache-control: no-cache.

Here is the shape of the repro I used, with the actual project URL/token omitted:

# Upload an image to a private bucket with immutable cache metadata.
curl -X POST \
  "$SUPABASE_URL/storage/v1/object/my-private-bucket/test.avif" \
  -H "Authorization: Bearer $SERVICE_ROLE_KEY" \
  -H "apikey: $SERVICE_ROLE_KEY" \
  -H "Content-Type: image/avif" \
  -H "Cache-Control: public, s-maxage=31536000, max-age=31536000, immutable" \
  -H "x-upsert: false" \
  --data-binary @test.avif

# Create one signed URL with a long expiry.
curl -X POST \
  "$SUPABASE_URL/storage/v1/object/sign/my-private-bucket/test.avif" \
  -H "Authorization: Bearer $SERVICE_ROLE_KEY" \
  -H "apikey: $SERVICE_ROLE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"expiresIn":1576800000}'

# Then reuse the returned signedURL exactly.
for i in 1 2 3 4; do
  curl -sS -o /dev/null -D - "$SIGNED_URL" \
    -w "attempt=$i ttfb=%{time_starttransfer} total=%{time_total}\n" \
    | grep -Ei '^(HTTP/|cf-cache-status:|age:|cache-control:|etag:|expires:|last-modified:|attempt=)'
done

Observed headers on repeated GETs look like this:

HTTP/2 200
cf-cache-status: REVALIDATED
etag: "..."
expires: <far future date based on signed URL expiry>
last-modified: <object timestamp>

A HEAD request to the same signed URL returns:

HTTP/2 200
cf-cache-status: MISS
cache-control: no-cache
etag: "..."
expires: <far future date based on signed URL expiry>
last-modified: <object timestamp>

For comparison, a public bucket object on the same project behaves as expected:

cf-cache-status: HIT
age: <increasing>
cache-control: 31536000

So the CDN is working generally; the behavior seems specific to private signed object URLs.

I found this older issue, which says signed URLs missing cache was expected at the time: supabase/supabase#23406

But the current Smart CDN docs now say signed URL responses are cached at the edge and that subsequent requests using the exact same signed URL should receive a cache hit: https://supabase.com/docs/guides/storage/cdn/smart-cdn#signed-urls-and-cdn-caching

Is REVALIDATED on every request expected for private signed URLs, even when the same signed URL is reused and the object has immutable cache metadata? Or should these eventually become HIT responses?

If there is any extra metadata or signed URL option needed for immutable assets that never change, I would be happy to try it. I could not find a documented way to override Cache-Control on the signed URL response itself.

[Hallidayo]

Moved across from supabase/supabase repo, @matiasvillaverde thanks you opening

[matiasvillaverde]

@Hallidayo sorry, I missed this repo. I will review it again, to see if I can get more information or the issue is duplicated

[matiasvillaverde]

It still seems a valid issue, let me know if you have any questions @Hallidayo

Supabase Storage code appears to set Expires for signed URLs and skip normal Cache-Control handling, which plausibly forces Cloudflare into validation instead of stable HIT

[matiasvillaverde]

I reviewed the current Storage source and opened a draft PR with a small proposed fix: #1188

What I found:

• Signed object GET routes pass expires: new Date(exp * 1000).toUTCString() into the renderer so the response includes an Expires header based on the signed URL token expiry.
• The shared renderer currently skips normal Cache-Control handling whenever options.expires is present.
• As a result, object cacheControl metadata can be stored correctly but not emitted on signed object responses.

The draft PR keeps the existing Expires header and also emits the object Cache-Control metadata when present. That seems to match the current Smart CDN docs, which say expiresIn and object cacheControl are independent for signed URLs.

I added two regression tests:

• renderer-level coverage that Expires does not suppress Cache-Control
• signed object route coverage that /object/sign/... returns both expires and object cache-control

Leaving it as draft because I realize this touches the signed URL cache semantics introduced historically around JWT expiry, so I would appreciate confirmation that the current docs reflect the intended behavior.

[matiasvillaverde]

Small follow-up: I re-reviewed the renderer call sites and updated the draft PR to cover signed transformed image responses too. The shared renderer is used by both /object/sign/... and /render/image/sign/..., so the PR now includes a route-level regression for the signed image path in addition to the signed object route and renderer-level tests.

[Hallidayo]

@matiasvillaverde - This is great thanks for your work on this 🎉

[fenos]

@matiasvillaverde unfortunately we cannot return the cache-control header on signed url, since that could expose a security issue where the browser would cache the file for potentially much longer than the signed url expiration was meant for.

This is the right behaviour for caching expiring URL.

In the future, we will be working at validating the signed url at the edge and at that point we might be able to return more consistent caches for further fetches

[matiasvillaverde]

@fenos I don't think the issue is closed. This is a blocker for us, and the CDNs are not working properly.

Validating the signed url at edge is the right approach. But right now this is a valid open issue

[matiasvillaverde]

@fenos @Hallidayo

I updated the PR to avoid returning the object's raw Cache-Control` on signed URL responses.. This should preseve the security property you called out, while still allowing repeated request for the exat same signed url to become edge hit while the token lifetime

[fenos]

@matiasvillaverde i'm not sure i fully understand here,
the Expires header is a date that when passed through the CDN, the CDN honours it and caches it for that long.

Since the Expires header is the exact date of when the exact signed url would expire, you should be getting cache hits continuously when using the same signed url, up until the Expires date elapses.

If you are noticing a different behaviour, this should not be the case.
Your PR uses the expiry date or the cache-control set during upload (which ever is lower) which is semantically incorrect, on signed url we should only rely on the Expires header

If you have a Supabase project, you can send us a support ticket, and we'll deal with it

[matiasvillaverde]

@fenos I've verified this again, Same exact signed URL, GET repeated from 4 Cloudflare colos on two projects: first request MISS, every subsequent request REVALIDATED... never HIT, despite Expires being decades away. A public object on the same project goes MISS→HIT normally.

Self-hosted storage (v1.29.0) behind Kong returns only Expires with no Cache-Control, as the OSS code does, but on Supabase Cloud, HEAD responses to signed URLs return cache-control: no-cache, which per RFC 9111 overrides Expires and marks the edge entry permanently stale.

So the platform edge layer is injecting no-cache on signed responses, and ""rely on the Expires header" cannot work while it does. This also contradicts the Smart CDN docs, which state signed-URL responses are served from edge cache until the CDN cache duration expires. Happy to open share a project, but this reproduces on any project.. cf-ray IDs available on request