Storage: Private bucket files are still accessible after you remove access or logout

[supabase-troubleshoot-docs-app[bot]]

A user can sometimes still download a file from a private bucket after you remove their access. This happens after you change an RLS policy or sign the user out. It affects files requested through the authenticated endpoint:

https://[project_id].supabase.co/storage/v1/object/authenticated/[bucket]/[asset-name]

Cause

A cached response skips the Storage service's access check. Two caches can do this:

• The browser cache can answer the request without contacting Supabase. See cache eviction.
• The Storage CDN caches a file based on the user and their access at the time of caching. It keeps serving that response until the user's access token (JWT) expires. This includes after the Auth session ends.

Fix

• If an RLS change removed the user's access, purge the CDN cache. The next request is checked against your current access rules. The purge can take up to 60 seconds to propagate.
• To shorten how long the CDN honors a signed-out user's access, lower the access token expiry in your project's Sessions settings.

A purge doesn't clear browser caches. For files you might need to revoke, set a shorter cacheControl value when you upload them.

Prevent

Use signed URLs to serve private files. You control access with an expiry time.

Other options:

• Use the S3 API, which doesn't use caching.
• Route requests through custom code (e.g. Edge Functions), which checks current access rules and sign-in state before it fetches the file.

[AppFirstAid]

You're not imagining it: after logout or an RLS tighten, a browser can still GET an object it already fetched because the JWT is still valid until expiry and the response may be cached.

Practical mitigations:

1. Serve authenticated objects with Cache-Control: private, no-store (and avoid long-lived CDN cache on that path).
2. 2. Prefer short-lived signed URLs for downloads instead of relying on the session JWT alone.
3. 3. On logout, clear client storage of any object URLs you handed out and don't reuse them.
      If it still reproduces after a hard refresh with a fresh anonymous session, that's a stronger signal for the Storage team.

[jorgeurios]

If you go the signed URL route, two things make it hold up when access changes.

Keep the expiry in minutes, not days, and generate the URL at the moment of download, not when you list the files. Signing a whole folder listing for 24 hours means anyone you remove keeps working links for the rest of the day.

For immediate revocation you still need the third option, your own endpoint that checks current access on every request before it signs or serves.