Reauthorize the requester and issue a fresh narrowly scoped link rather than editing its expiry or making the object public.
When a private signed download link expires, return through the application’s supported access route and request a newly authorized link. Do not change expiry text in the URL, make the file public or send an administrator credential to the recipient. The file can remain private while the application issues another limited opportunity to retrieve it.
Separate three objects: the requester’s entitlement, the stored file and the temporary link. Expiration of the last one does not necessarily remove the first two. Conversely, possessing an old email or account page does not prove entitlement is still current.
Establish what failed before issuing anything
Record the failed stage, time, response category and expected file identity without copying the full signed URL into a ticket. A refusal can reflect expiry, changed permissions, a missing object, altered request parameters or another layer’s policy. Read the provider’s safe diagnostic details with the authorized maintainer.
A downloaded file opening in a viewer or saving under an unexpected name is another problem. The download filename and viewer guide covers that representation boundary. Do not weaken private access to solve a filename issue.
If the file is absent or replaced, establish which version the recipient is entitled to receive. A newly valid link to the wrong file is not a repaired delivery. Use stable internal file identifiers in the application’s records, while keeping credentials and complete capability URLs private.
Understand the bearer capability
Amazon S3 describes presigned URLs as bearer tokens: possession grants their permitted access, subject to the relevant policy and validity. This is a useful model for understanding why such links belong in the secret-handling boundary. It does not mean every signed-link service has identical rules.
Protect the complete URL, including its query string. It can appear in browser history, server logs, support screenshots, analytics and copied messages. A short visible label such as Download report does not reduce the sensitivity of the underlying destination.
Use a lifetime proportionate to the task and provider capabilities. A very short period can create avoidable failures for a reader who needs time to find the message or begin a large transfer. An unnecessarily long period extends exposure. Define the expected journey instead of choosing a universal number.
| Observation | Check next | Safe outcome |
|---|---|---|
| Old link reports expiry | Current requester entitlement | Issue a fresh scoped link if still permitted |
| Link fails before its displayed lifetime | Signing credential lifetime and policy | Repair issuance under supported provider rules |
| Link works for anyone holding it | Whether that bearer behavior is intended | Protect distribution or choose a stronger application gate |
| Expired link still seems to display a file | Local or intermediary cached copy | Separate stored representation from new origin access |
| Transfer stops and resume fails | New range request and link validity | Supported renewal/resume route |
A fictional private report
A fictional publisher offers a private monthly report to authorized members. A member opens an old notification after the link’s lifetime has ended. The report still exists and the membership remains active, but the link no longer authorizes retrieval.
The member signs in through the publisher’s known account route. The application checks the member’s current access to that exact report and creates a new limited download link. The member uses it without the report being placed in a public media directory.
In another fictional variation, the member’s access has ended. The application explains the supported assistance route and declines renewal. Reissuing solely because the old URL looks genuine would bypass the current entitlement decision. These are proposed workflows, not a claim that a specific service was tested.
Reissue access rather than modifying a signed URL
- Identify the requester through the application’s supported authentication or delivery proof.
- Check current permission for the exact file and operation.
- Confirm the object exists and represents the intended version.
- Generate a fresh scoped link through the maintained server-side integration.
- Deliver it through the approved route without logging its complete value.
- Record issuance metadata and the result, with secrets omitted.
Do not let an arbitrary browser-supplied file path determine what a privileged signer authorizes. The application should map a legitimate entitlement to an allowed object. Hiding the signer behind a server endpoint does not make that endpoint safe if it signs any requested path.
Expiry and one-time use are different contracts
Cloudflare R2 documents that a presigned URL can be reused until expiry. That is a concrete example of why temporary should not be described as single-use. A one-time redemption workflow requires additional application state and a supported design.
S3 also documents that a presigned URL can expire when its underlying credentials expire, even before the requested lifetime ends. Read the actual storage service’s contract before diagnosing an early refusal or promising a recipient a precise availability period.
Changing a signed parameter normally changes the signed request, so editing the expiry is not legitimate renewal. Likewise, rotating a signing credential can affect multiple outstanding links. Use documented revocation and rotation behavior; do not assume one universal per-link revoke button exists.
Download expiry cannot retract saved bytes
RFC9111 distinguishes private and no-store caching behavior. Private limits shared-cache storage; no-store addresses storage of the response, with explicit privacy limitations. Neither directive reaches into a recipient’s saved file and deletes it after download.
The private-page caching guide helps review account pages that expose these links. Check the link-bearing HTML and file response separately. An account page may need a different policy from a static public article, and an intermediary must not serve one member’s private response to another.
If a browser resumes a transfer after an interruption, a new request may encounter expiry even though the original transfer began while valid. The HTTP range guide explains partial retrieval. Establish the provider’s behavior before promising that one successful start guarantees every later resume.
Give the reader a useful recovery route
Explain an expired link without suggesting the file became public or the person must pay again. Offer the supported sign-in, refresh-link or assistance action. Preserve the distinction between a technical renewal failure and a current access refusal.
Your next step is to rehearse one expired-link case in staging with a synthetic account and file. Verify current entitlement, fresh issuance, the correct downloaded object and denial for an unauthorized account. Record any untested cache or resume behavior as a limitation. The desired outcome is restored authorized retrieval while the private-file boundary remains intact.
Sources and verification
Editorial review 2026-10-17. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- Amazon S3: Presigned URLsChecked Bearer capability, expiry and signing-credential lifetime.
Limits: S3-specific rules illustrate, but do not define, every signed-link service. - Cloudflare R2: Presigned URLsChecked Object/operation scope and reuse before expiry.
Limits: R2 implementation example; no universal one-use or immediate-revocation guarantee. - RFC9111: HTTP CachingChecked Private and no-store response semantics and privacy limitations.
Limits: Cache directives do not retract files already saved by recipients.