Define the Cancellation Policy Before Revoking Access
Cancellation is a business event, not a universal instruction to delete files or remove every organisation member. A subscription may end immediately, remain active until the paid period ends, or permit a limited export window. Removing one user from an organisation is also different from cancelling the organisation's subscription.
Write the effective entitlement date and the intended treatment of shared files first. Decide whether the cancelled user loses only authenticated access, whether external share recipients should lose access too, and whether other paying members must retain the file. The following procedure is a proposed implementation policy for a hypothetical product, not a statement that any particular system has passed the tests.
For a confidential shared document, the important distinction is between a request that checks the user's current permission and a previously issued bearer link. Revoking membership can govern the first path while the second remains usable. Treat them as separate surfaces in the access inventory.
Map the Paths That Can Still Deliver a File
Inventory the application preview, file listing, metadata endpoint, authenticated download, signed-link creation endpoint, existing signed URLs, exports and background workers. A route can expose a filename or client name even when the bytes are denied. Include browser, application and CDN caches in the inventory.
| Access path | What must govern the decision | Cancellation implication |
|---|---|---|
| File list or metadata API | Current membership and field scope | Deny protected metadata to withdrawn member |
| Authenticated download | Current entitlement and object authorization | Deny new protected requests |
| Signed-link minting endpoint | Current membership and share permission | Stop creating new links |
| Previously issued signed link | Bearer token and delivery cache behavior | Does not automatically follow membership change |
| Export archive | Current export grant and archive scope | Deny new downloads where the policy requires it |
| Privileged worker | Server-approved organisation and action | Must enforce scope even if its credential bypasses RLS |
OWASP recommends authorization checks for every request. Apply that principle to each route and worker above, rather than treating a hidden download button as a permission boundary. OWASP authorization guidance
Check Current Membership Where Prompt Revocation Is Required
Record the effective cancellation or removal in server-owned entitlement and membership data. Protected endpoints should read the state that implements the policy, then authorize the object and action. Do not trust a browser-supplied organisation ID or user-editable profile field.
RLS can constrain authenticated file requests when its policy checks the correct current membership relationship. Supabase Storage uses policies for access control, but a service key can bypass them. A server worker using that privileged credential must implement its own approved scope check before returning bytes or minting a link. Supabase Storage access control
Distinguish a database membership lookup from a membership claim embedded in a JWT. The first can see the changed server record on a new query. The second can remain stale until a fresh token is issued. A valid JWT signature confirms the token's authenticity; it does not prove that its organisation permissions are still current. Supabase JWT authorization guidance
Refreshing a cooperating client can improve its display, but a withdrawn user can retain an old token. Revoking refresh capability alone does not make every already-issued access token unusable on every endpoint. For prompt enforcement, test the existing token against the current-state permission check. Any token denylist is an additional application mechanism that must actually be consulted by the delivery path.
Also inspect view and function execution context. A view created with a privileged owner can bypass expected policies. Test the route's effective role and grants, not only a policy run through an administrator console.
Understand the Existing Signed-Link Boundary
Supabase private Storage supports authenticated requests and signed URLs. Its Storage URL signing key is separate from Auth JWT signing keys. Rotating those Auth keys therefore does not revoke existing Storage signed links; the download documentation directs customers requiring signed-link revocation to Supabase support. Supabase private downloads
A signed URL is usable by its holder within the provider's token and delivery rules. The recipient need not be the member who originally requested it. Removing that member, logging them out, or changing an application share record does not insert a fresh membership check into an already-issued direct Storage URL.
Short link lifetimes reduce the origin validation window, but response caching introduces another lifetime. Smart CDN can continue serving a previously warmed signed response after token expiry until the cache duration ends. Token expiry and cache duration are independent; expiring a token does not itself purge that response. Supabase signed URL caching
For a product promise that one withdrawn user loses new downloads promptly while others keep access, use an authenticated delivery endpoint or gateway that checks current entitlement and has a verified private-cache policy. If it redirects to a reusable signed link, that link still needs its own threat and cache analysis. This is a design recommendation, not a provider guarantee of instant revocation.
Treat Object Removal as a Separate Operation
Deleting a file affects every recipient and may destroy data that other members still need. It is not a routine per-user cancellation mechanism. Moving or renaming a file can also affect references and retention, and should not be presented as a guaranteed instantaneous cutoff.
Supabase documents that deleting an object invalidates its CDN entries, with propagation taking up to a minute. Browser-held copies can persist independently. Updating or deleting an object therefore needs a timed test and a recorded scope; it cannot support an unconditional “access denied immediately” claim. Supabase cache invalidation
Use object removal only when the approved policy or incident response calls for it. Verify backup and recovery requirements before destructive action. Database backups should not be assumed to contain the actual Storage objects. Neither deletion nor any other permission change retracts bytes already downloaded by a recipient.
Adding a cache-busting query parameter can help a tester inspect a fresh origin path. It does not force a hostile recipient to stop requesting their original warmed URL. Keep the original URL in the warm-cache test rather than using a new URL and calling the result revocation evidence.
Filled Hypothetical Cancellation Policy
Suppose Thabo leaves organisation A while other members retain access to a confidential report. The quantities and timings below are proposed fixtures.
| Policy decision | Proposed value | Reason |
|---|---|---|
| Effective removal | Membership revoked at recorded time T0 | Clear boundary for new authenticated requests |
| Remaining members | Keep their authorized report access | One departure should not delete shared data |
| New share links | Thabo cannot create them after T0 | Share creation checks current membership |
| Existing direct signed link | Inventory and test separately | Membership removal does not revoke bearer token |
| Future confidential sharing | Controlled authenticated delivery | Supports current per-request entitlement checks |
| Retention | Preserve report under organisation policy | Cancellation is not automatic data destruction |
| Incident exception | Separate approved object-removal procedure | Avoid accidental loss for other members |
Record the policy version, actor, organisation, member, effective time and affected share identifiers. Store link identifiers or redacted references rather than full signed query strings in general logs.
Revocation Acceptance Matrix
Run these tests with two ordinary users, a known report and the actual delivery configuration. Record request time, endpoint, effective role, status, returned metadata and cache observations. These are expected results for the proposed policy, not completed live checks.
| Test | Expected result | What it proves |
|---|---|---|
| Active member before removal reads report | Authorized bytes returned | Positive control for the test fixture |
| Thabo after T0 lists or reads metadata | No protected names, paths, counts or contents | Metadata is protected too |
| Thabo reuses old JWT for authenticated download | Denied by current membership check | Stale token cannot override server state |
| Thabo requests a new signed link after T0 | Denied without exposing object details | Minting boundary works |
| Thabo reuses existing unexpired signed link | May still return bytes | Known direct-link limitation |
| Never-warmed signed link after token expiry | Origin validation denies access | Token expiry tested without warm cache |
| Same signed URL warmed before expiry and reused later | May return cached bytes until cache duration ends | Cache lifetime measured separately |
| Remaining member reads the same report | Allowed under current membership | Revocation scope did not break other members |
| Optional approved deletion of test object | Record origin denial and CDN invalidation delay | Global object removal tested without instant promise |
Use a documented endpoint deny contract. An API might return 401 for absent authentication, 403 for a forbidden authenticated request or a consistently masked 404; a policy-filtered SELECT can return no rows. The decisive check is absence of protected bytes and metadata, not one universal status code.
Include the production-equivalent CDN tier and settings in evidence. A staging environment without the same caching behavior cannot establish the live response lifetime. Distinguish edge hits from browser cache and test in a fresh client as well as the original browser.
Recover From a Failed Revocation Test
If the authenticated path still allows access, inspect current membership queries, effective database role, privileged credentials, views and stale application caches. Repair the enforcing boundary and repeat the old-token test. For a queued export, cancel or reauthorize the job rather than delivering it based on the original request alone.
If only an existing direct signed link works, do not label the membership check broken. Record the known bearer-link exposure and use the chosen incident or provider-support procedure. Revisit the delivery design if the observed lifetime conflicts with the product's promise.
Close the test only after positive and negative cases pass, remaining members still have intended access, and the observed link/cache behavior is documented. A cancellation event received by the application is not, by itself, proof that every file delivery path has stopped.
If your business needs expert help securing file access and managing user permissions, explore our SaaS development services. For detailed guidance on platform choices, see our CMS vs custom development guide. To understand ongoing costs, review website maintenance costs. Learn about user flow impact in our user journey glossary.
If you need help implementing secure revocation mechanisms, get in touch via our SaaS development route.
Frequently asked questions
How quickly can revoked users lose access to shared links?
Current-state authorization can deny new authenticated requests after the effective removal. Existing signed links and cached responses follow separate lifetimes, so measure those paths before promising a cutoff.
Can signed URLs be revoked before expiry?
Check the specific provider's mechanism. Supabase directs customers needing signed-link revocation to support; Auth key rotation is ineffective for Storage links. Object deletion affects all recipients and CDN invalidation can take up to a minute.
What role does row-level security play?
A policy that reads current server-owned membership can deny a withdrawn user despite an old valid token. A policy relying only on token membership claims can remain stale, and privileged roles may bypass RLS.
How do CDN caches affect access revocation?
A warmed signed response may outlive token expiry. Test the original cached URL separately from a fresh origin request; adding a new query parameter does not revoke the recipient's old cache entry.