An exported file creates a new copy of data with its own access path and lifetime. The permissions that protect an application screen do not automatically follow a CSV attachment, a storage object, or a shared download link. Design export delivery as a sequence of authorization decisions: who can request the dataset, which worker can create it, who can retrieve the result, and when that result should disappear. Each stage needs an owner and an observable outcome.
Start with the smallest useful dataset
Ask what the recipient needs to accomplish before deciding which columns to include. An operations report may require order identifiers and totals without customer notes, internal fraud flags, or full addresses. Define named export profiles with reviewed fields, filters, and audiences. Treat additions to a profile as a deliberate change, because an extra column can widen the sensitivity of every file generated by an existing recurring schedule.
Record the tenant, requester, permitted scope, selected profile, and intended destination with the job. Derive account boundaries from authenticated server context rather than trusting a client-supplied account identifier. If a user supplies filters, validate them within the scope already authorized. The customer data export overview is a useful starting point for connecting those decisions to the audience and purpose of the file.
Authorize the work at meaningful boundaries
Check permission when accepting the request and decide how later permission changes affect pending work. For a long-running export, it may be appropriate to recheck before generation and again before issuing a download. Make the policy explicit. A user removed from an account while a report is queued should not obtain the completed file simply because the original request was valid. Service-owned schedules need a current accountable identity as well.
Authorize every job status and artifact request against the requesting principal. An unpredictable job identifier is helpful for avoiding accidental collisions, but it is not an authorization rule. Test whether a person from account A can inspect, cancel, regenerate, or download an export belonging to account B. Include secondary endpoints such as previews, validation reports, and failed-row files, since they may reveal the same underlying data.
Keep generated artifacts private
Write artifacts to private storage with access limited to the components that need it. Separate incomplete work from published results, and avoid storing files beneath a public web directory by default. Give the generation worker permission to write its designated outputs without granting unrestricted access to unrelated datasets. Give the delivery component only the read and signing permissions its workflow requires. Apply equivalent controls to temporary files and failed attempts.
Use encrypted transport and appropriate encryption at rest, but also review who can use the associated keys and credentials. Encryption does not compensate for an application that hands a valid download to the wrong account. Keep storage paths and filenames free from unnecessary personal information. A random artifact identifier plus a descriptive download filename usually gives a cleaner separation between internal storage organization and the name a recipient sees.
Understand what a signed URL grants
The Amazon S3 documentation for presigned URLs describes them as bearer tokens: whoever possesses a usable link can exercise its granted access. It also explains that a link can expire when its signing credentials expire, even if a later expiration was requested. These properties make link handling and credential lifetime part of the delivery design.
Issue a narrowly scoped download capability only after authenticating and authorizing the requesting user. Select a lifetime that fits the expected download interaction and the data's sensitivity. Show the expiry clearly and provide an authenticated way to request a fresh link while the underlying artifact is still retained. Avoid placing reusable signed URLs in public pages, analytics events, support transcripts, or routine logs. Redact query parameters that contain access capabilities.
A signed link is not inherently single-use. If your workflow requires one-time retrieval, enforce that behavior through a controlled application gateway or another mechanism with durable redemption state, and define what happens when a connection breaks. A recipient who downloads a file already possesses a copy; expiring a link cannot erase that copy. This boundary should inform both product language and expectations about revocation.
Match revocation promises to the access mechanism
Consider a contractor who receives a download link at 09:00 and loses account access at 09:05. Removing the contractor from your application does not necessarily invalidate a capability already issued by an independent storage service. The link's own expiry and the storage authorization mechanism still matter. Document that distinction when deciding how long links should last and what a revoke action actually does.
If access must be checked against current membership for every new download request, use an application-controlled route that performs that check before serving the artifact. Plan how range requests, interrupted downloads, and caching interact with the rule. Disabling future requests cannot retract bytes already delivered. Clear boundaries let product owners choose an appropriate delivery experience without promising a level of control the mechanism cannot provide.
Choose the destination deliberately
Delivery to an authenticated application portal keeps access decisions close to the account. Delivery to a customer-controlled storage destination can fit automation, but requires verification of the destination and a review of the credentials used to write there. Sending the file as an email attachment creates copies outside your application's direct control. Select the channel based on the dataset and the recipient's workflow, not merely whichever transport is easiest to implement.
| Destination | Design question | Useful control |
|---|---|---|
| Application download | Does this person still belong to the account? | Authorize at download time |
| Customer storage | Does this location belong to the intended customer? | Verify destination ownership and scope write access |
| Email notification | Could forwarding expose the dataset? | Prefer an authenticated portal link for sensitive exports |
If users can configure webhook or storage endpoints, validate destinations and control outbound network access. Do not let an export worker become an unrestricted fetch or upload proxy into internal services. Revalidate redirect targets where redirects are allowed, and use a reviewed destination registration process for recurring deliveries. Keep the customer-facing setup understandable while maintaining the server-side checks behind it.
Set separate lifetimes for files and links
Artifact retention and access-link expiry solve different problems. A file might remain available for an agreed reporting period while each download link lasts only long enough for an authorized interaction. Record both timestamps independently. Deletion should cover completed outputs, temporary chunks, alternative formats, previews, and generated error reports. Check whether replicas, versioned objects, or backups have separate retention behavior, and describe any material difference in the operational policy.
For recurring schedules, decide whether a new file replaces the discoverable previous version or simply adds another retained artifact. Set quotas and cleanup rules accordingly. A deletion worker should produce a verifiable outcome and surface failed cleanup. Avoid indefinite retention caused by repeated delivery failures. The scheduled export design guide explains how retention and retry windows need to agree.
Audit decisions without duplicating the dataset
Log who requested an export, the authorized account, the profile version, the resulting artifact identifier, and key state changes. For retrieval, record the access decision and a suitable request correlation identifier. Keep raw records, full download capabilities, and unnecessary personal data out of the audit stream. Restrict audit access separately from ordinary application monitoring, and choose retention that serves investigation needs without recreating a long-lived copy of sensitive information.
Define an incident action for the delivery path. If a link is exposed, operators should know how to disable the artifact or its serving route and prevent new link issuance. If credentials are exposed, rotate or revoke the relevant credentials and investigate their scope. Preserve enough evidence to determine which files and accounts were involved. Test the recovery procedure with a harmless sample artifact before depending on it during an incident.
Verify the entire lifecycle
Use representative test accounts with different permissions. Check cross-account access, revoked membership, expired links, deleted artifacts, invalid destinations, and interrupted cleanup. Inspect responses and logs for leaked metadata as well as file contents. Review export security considerations alongside the implementation, and revisit them whenever a new format or delivery channel is introduced. Secure delivery works when the right person receives the minimum useful data, every access path enforces that decision, and the resulting copies have a defined lifecycle.
