Private downloads for MENA SaaS: access and expiry

A customer leaves a project, but the download link they copied still opens its documents. The application has removed their membership. The storage service is honouring a permission that was issued earlier.

For a MENA SaaS product handling supplier invoices, property records or customer exports, this is a design decision worth making explicitly. A signed URL delegates access for a defined operation and period. It does not automatically follow every later change to the application's permissions. AWS describes presigned URLs as bearer tokens; Google likewise says anyone holding an active signed URL can use it.

This guide focuses on access after a document is ready for release: choosing the delivery path, containing cache exposure and defining what revocation actually means. Upload scanning belongs to a separate quarantine-and-release workflow.

Cover: original SultanByte artwork showing an application permission check, a temporary download grant and a private document.

Decide what the download promise means

Write a short contract before choosing a signing library. Who may request the document? Does removal from a project need to block the next request immediately, or is a bounded period of delegated access acceptable? Can the same grant be reused? What happens when a large download needs to resume?

A useful default for this proposed design is a download broker: an authenticated application endpoint that resolves an opaque document ID, checks the current actor's access and selects the delivery method. Do not accept a client-supplied bucket, object key or arbitrary destination URL as the authority for that decision.

OWASP's authorization guidance recommends denying access by default and validating permissions on every request. Apply that rule to the broker, including replacement-link requests. With direct signed delivery, the storage service subsequently evaluates the delegated grant, not your live project-membership record.

Keep the document's owner, approved storage location and exact content version in a server-controlled record. A customer changing a document ID must not cause the broker to sign another tenant's object. A successful malware scan is also not evidence that the requester may read it.

Choose between direct delivery and a proxy

Use direct signed delivery when the product accepts a short delegation window and benefits from keeping file traffic away from application servers. The broker authorizes the request and issues narrowly scoped read access. The client then downloads from storage through the intended route.

Use an authenticated streaming proxy when the product requires a fresh application decision for each new download request. The proxy must actually carry the bytes; an endpoint that authenticates and then redirects to a reusable storage URL has returned to delegated access. Budget for bandwidth, concurrent connections and recovery from interrupted transfers.

This is a proposed decision aid, not a claim that one option is universally safer:

• For ordinary private exports with an accepted delegation window, start with direct delivery and a tested expiry policy.
• For documents whose access must stop promptly after an entitlement change, evaluate a proxy that checks current authorization on every new request.
• For repeated delivery where edge caching is intentional, use an access-controlled CDN design with authorization before cache delivery and a protected origin.

A proxy still cannot recall bytes already saved by a recipient. Nor does checking a request once automatically terminate an active stream when membership changes. If mid-transfer termination is a requirement, design and test that separately rather than promising it through the word “revocation.”

Original infographic: SultanByte. Proposed decision framework informed by OWASP, AWS, Microsoft, Google Cloud and RFC 9111 documentation, October 2026. The steps are design guidance, not measured performance.

Read the provider's expiry and revocation rules

Amazon S3's presigned-URL documentation says a URL can be used repeatedly until expiry. Temporary signing credentials can expire earlier than the URL's requested lifetime. S3 checks expiry when the HTTP request starts: a download begun before expiry can continue, while a restart after expiry fails.

That means “expires at this time” is not the same as “all transfers end at this time.” Keep the interface honest and provide an authenticated way to request a replacement link. The replacement must pass a new authorization check; it should not be minted merely because the client presents an old URL.

For Azure Blob Storage, Microsoft recommends a user delegation SAS when possible. Its documentation distinguishes that mechanism from service and account SAS. Stored access policies apply to service SAS, not user delegation or account SAS, so a revocation runbook must name the actual SAS type. Microsoft also warns that Storage does not track generated SAS tokens for you.

For Google Cloud Storage, signed URLs use XML API endpoints. Google's documentation describes possession-based access until expiry or rotation of the signing key. Do not transplant an S3 helper or assume that an application logout invalidates this separate capability.

Keep a provider-specific record of the signing identity, permission scope, expiry constraint and emergency invalidation method. Record the expected blast radius of that method. Rotating a shared signing key may affect more than the one document or recipient involved in an incident; it is not a substitute for choosing a suitable access model.

Treat cache policy as a separate boundary

For sensitive downloads where caching is not intended, start with Cache-Control: no-store on both the broker response containing the grant and the file response. Verify the delivered headers rather than assuming that a header on the API response also controls storage or CDN responses.

RFC 9111 gives these directives different meanings. no-store prohibits a compliant cache from storing the request or response for reuse. private prevents shared-cache storage but permits private-cache storage under the applicable rules. no-cache allows storage but requires validation before reuse. None is a mechanism for deleting a file someone deliberately downloaded.

Configuration can defeat the intended policy. AWS warns that a CloudFront minimum TTL greater than zero causes caching for that minimum even when the origin sends no-cache, no-store or private. Inspect the deployed cache policy and path matching, not only application code.

If edge caching is deliberate, distinguish a CDN's own signed access mechanism from a storage presigned URL placed behind an ordinary caching layer. CloudFront's signed-URL flow validates the signature and policy before checking its cache. Its documentation also says that new range requests after expiry fail. A cache hit is therefore compatible with controlled delivery when the viewer check remains in front of it. There is an important method exception: CloudFront does not require signatures for OPTIONS requests. If those requests are allowed, the origin must not return protected content in response.

For a custom proxy or CDN, require evidence of that ordering. Warming a cache as an authorized user must not make the object readable through an unsigned request. Do not assume that including a token in the cache key proves expiry enforcement; a cached response and a current authorization decision are separate concerns.

Keep regional routes and operational records explicit

For a Saudi deployment and a UAE deployment, create separate delivery-route records where the customer's architecture requires them. Name the document store, broker, optional edge cache, logging destination and support-access path. Confirm the approved route for each deployment instead of relying on a generic “MENA” configuration.

This is an engineering review, not a statement that either country requires every document to remain locally stored. The relevant business, contractual and regulatory requirements need their own assessment. This guide is practical information, not legal advice.

Treat a full signed URL as a credential in operational tooling. Microsoft's SAS guidance warns that anyone obtaining a leaked SAS may use it; the same possession risk is explicit in the AWS and Google documentation. As an implementation policy, omit query strings from download telemetry, redact grant values from error reports and keep them out of support tickets. Test those rules through the actual logging pipeline.

Record a non-secret grant ID, document/version reference, actor, authorization outcome and expiry instead. Keep grant issuance distinct from a completed download: an API returning a link does not prove that the recipient fetched the file. Where delivery logs provide useful evidence, define what they establish without equating a successful HTTP response with a human reading the document.

For Arabic and English interfaces, localize the explanation of an expired link and preserve the accepted download name through a validated header builder. SultanByte's Arabic filename guide covers that boundary. Do not use the display filename to reconstruct the storage location during a retry.

Test the access contract before launch

Use synthetic files and two isolated test tenants in the deployed non-production stack. The following cases are a proposed acceptance suite, not benchmark results:

1. Request another tenant's document ID. Require denial before any grant is issued, and confirm that neither the body nor a redirect contains a usable download location.
2. Copy a direct signed URL into a client without the application session. Verify the expected bearer-access behaviour during its valid window. If that behaviour contradicts the product promise, change the delivery design.
3. Remove membership after grant issuance. Test the old grant and a request for a replacement separately. Require replacement denial, and document the old grant's actual validity boundary.
4. Warm the delivery cache, then try unsigned, tampered and expired requests. Repeat against the origin and alternate hostnames to expose a bypass route.
5. Interrupt a large transfer around expiry. Test the browser or SDK's real resume behaviour, including range requests. Ensure renewal never bypasses current authorization.
6. Exercise the chosen emergency invalidation procedure. Measure when new requests stop succeeding and identify unrelated grants affected by the action.
7. Inspect telemetry, error reports and support exports for synthetic grant values. A redaction rule that works only in the application's main log is incomplete.

Assign an owner to failed renewals and emergency revocation before enabling private downloads for customers. The release decision should rest on observed access behaviour: who can obtain a grant, who can use it, what happens after permissions change and whether a cached copy bypasses the intended check. A short expiry is useful only when the rest of that contract is understood.