Work out who can upload a document, where it belongs, how it is checked and who can open it later. Those rules are what turn an upload button into a dependable document workflow.
A customer uploads a quotation and sees the progress bar finish. Has the file arrived? Has it been checked? Can the right staff member open it—and can someone from another customer account do the same?
Those questions should be settled before a portal starts collecting business documents. Moving files out of email may make them easier to organise, but the portal still needs clear rules for access, validation and retention.
Decide where each upload belongs
Start with the business process. Which user can upload, which account or case receives the file, and who needs to review it? The server must check that relationship. A customer ID supplied by the browser isn't proof that the user can add documents to that account.
Use generated object identifiers rather than predictable public file paths. Tell the customer about allowed formats, size limits and multiple-file rules before they start. Also ask whether the process really needs the document: collecting less sensitive material can be a better design choice than finding more places to store it.
Keep temporary access temporary
A presigned URL allows a defined storage operation for a limited time, without exposing permanent storage credentials to the browser. Cloudflare R2 documents this approach for its S3-compatible interface.
The URL is still access material. Someone who obtains it may be able to use the permitted operation while it remains valid. Limit the object, method and lifetime appropriately, and avoid sending the URL into general analytics or unnecessary logs.
Don't assume a presigned link can only be used once. If single-use behaviour matters, the application needs to implement and enforce it.
Don't trust the filename
An allowed extension or a browser-reported content type doesn't prove that a file is safe. Validate size, type and content on the server, and use appropriate malware inspection. Files awaiting checks shouldn't be available through the normal download route.
Keep uploads away from executable application paths. If the portal creates previews, include the preview service in the security review. Opening and processing an untrusted document introduces its own risks; it isn't merely a visual enhancement.
| Status | Meaning | What the customer needs |
|---|---|---|
| Transferring | The file is still being sent | Progress and cancellation |
| Checking | Inspection isn't finished | No premature acceptance message |
| Accepted | The required checks and record are complete | A clear receipt |
| Rejected | The file didn't meet the requirements | A safe, helpful explanation |
Check permission again at download
Access needs checking when someone requests the file, not just when the portal displays the file list. Try a direct URL, a different customer's identifier and a user whose project access has been removed.
If downloads use temporary links, consider how long those links remain valid and whether that is suitable for the document. Choose response headers and inline-versus-download behaviour deliberately. A customer relationship can change while an old public link remains usable.
Expect an interrupted upload
Someone will try to send a large file over an unreliable connection. Give them an understandable result: still transferring, checking, accepted or failed. A completed progress bar over a missing record is confusing for customers and difficult for support.
Agree how duplicates and abandoned transfers are handled. Give support staff enough information to investigate without granting everyone access to every customer document. A controlled support view is preferable to sharing unrestricted administrator credentials.
Set a retention rule before the files accumulate
Decide how long documents stay, who can remove them and how deletion affects backups, indexes and audit records. Have the organisation's data owners approve the arrangement; choosing a storage product doesn't, by itself, establish regulatory suitability.
For a Gligx customer portal project, include expired links, invalid files, cross-account requests and interrupted uploads in acceptance testing. Consider the sign-in journey alongside file access, so the two parts are tested together.
Sources and further reading
References checked on 23 October 2026.
Frequently Asked Questions
Is a private storage bucket enough to protect customer files?
It's one part of the design. You also need access checks, validation, appropriate inspection, retention rules and controlled downloads.
What is a presigned upload URL?
It's temporary permission for a defined storage operation. Treat the link as sensitive access material and limit what it permits and how long it lasts.
Can we trust a file because it ends in .pdf?
No. Check size, type and content on the server and use suitable malware inspection. A filename or browser-supplied type doesn't prove safety.
Should all staff be able to open uploaded files?
Only if their role genuinely requires it. Check account, case and role access for each request, with logging that fits your approved policies.