# Secure file uploads for MENA SaaS: quarantine and release

A customer uploads a document. The progress bar reaches the end, the application returns a download link, and a background scanner starts working. That sequence has already given someone access to a file the scanner has not assessed.

For a MENA SaaS product accepting identity documents, supplier invoices or property attachments, the release decision deserves its own design. This guide proposes a quarantine-first workflow: accept the bytes into restricted storage, evaluate the exact uploaded object, and grant normal access only after the required checks pass.

The focus is the interval between upload and release, rather than filename handling or general tenant isolation. The design applies to an Arabic or English interface and can be implemented separately in approved Saudi and UAE deployments. It does not establish where a particular business is legally required to store documents. This is practical engineering information, not legal advice.

*Cover: original SultanByte artwork showing an uploaded document held behind a release gate before authorised access.*

## Define what “uploaded” means

Give the product separate states for received, checking, released and blocked. A successful storage response should mean that the service received the bytes, not that the document is ready for a colleague to open. Show that distinction in the interface and in the API.

Start with a bounded upload contract: an authorised actor, a permitted destination, allowed document types and a size budget. [OWASP's file-upload guidance](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) recommends layered validation, generated storage names, restricted storage and malware checks where available. It warns that the client-supplied Content-Type can be forged and that a file signature is insufficient on its own.

Keep the accepted Arabic filename as display metadata rather than using it to select a storage path. SultanByte's [Arabic filename guide](https://www.sultanbyte.com/arabic-filenames-object-storage-downloads) covers that separate concern in detail. Here, assign each upload a server-controlled identifier and bind it to an owner before issuing upload permission.

For a first implementation, refuse archives unless the business genuinely needs them. If archives are necessary, specify limits for extracted content and processing work, not only the compressed upload size. Keep the parser and scanner behind resource limits so that one difficult document cannot consume the entire worker fleet.

## Quarantine must be an access boundary

In the proposed architecture, ordinary application users cannot read the incoming storage area. The upload client gets narrowly scoped write permission, while the scanner gets the access it needs to inspect the object. A separate release component decides what becomes available through the normal download path.

Do not make quarantine a folder name that every application role can still read. Review the effective permissions of the API, preview generator, support console and background workers. A thumbnail service that reads incoming files immediately has bypassed the same gate as an early download link.

Microsoft's [malware-remediation guidance](https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-storage-configure-malware-scan) describes using intermediary storage for untrusted content and forwarding files after a qualifying scan result. It also warns that broad storage-account permissions can still reach a quarantine container. The architecture therefore needs permission tests, not just separate labels in a diagram.

For a Saudi customer deployment and a UAE customer deployment, maintain distinct approved processing routes where your requirements call for them. Record the storage, scanner, event service and any later OCR destination for each route. Do not silently send documents to a public scanning website when the regional worker is unavailable. OWASP specifically warns about information leakage through public analysis services.

## Bind the verdict to the bytes

The release record should identify the exact content that was assessed. Store the upload ID, storage locator and immutable version reference where supported, together with the scanner result and decision time. If the design uses a content digest, record how it was computed and verified. A filename is not a content identity.

This matters when an uploader can replace an object while scanning is in progress. [Amazon S3's presigned-URL documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html) explains that a URL can be used repeatedly until it expires and that uploading to an existing key replaces the object. Issuing a URL is therefore not, by itself, a one-use upload protocol.

Design replacement as a new upload with a new release decision. Where the platform supports version-specific reads, scan and release that exact version. Otherwise, make writes immutable through the complete permission model and verify that the release operation cannot substitute a later object. A client-side “already uploaded” flag does not enforce this.

The same requirement applies when copying a file out of quarantine. Copy the assessed version, confirm the destination, then update the application record. Make recovery from a failed copy explicit. If a record says released while its destination is missing, the user should see an operational error, not a fallback link to untrusted storage.

## Treat incomplete scans as a different outcome

A scan result is evidence with a defined scope. “No threats found” does not prove that a document is authentic, free of every exploit, or suitable for an OCR or AI workflow.

[AWS documents](https://docs.aws.amazon.com/guardduty/latest/ug/monitoring-malware-protection-s3-scans-gdu.html) GuardDuty Malware Protection for S3 results including `NO_THREATS_FOUND`, `THREATS_FOUND`, `UNSUPPORTED`, `ACCESS_DENIED` and `FAILED`. Its unsupported cases include password-protected content and some archive or quota conditions. An access failure is not a benign verdict.

Microsoft's [Defender for Storage overview](https://learn.microsoft.com/en-us/azure/defender-for-cloud/introduction-malware-scanning) distinguishes results such as No threats found, Malicious, Error and Not scanned. It also notes that client-side encrypted blobs cannot be scanned and that blob index tags can be altered by identities with the relevant permissions. Do not let an uploader write the tag that the release service trusts.

Use an explicit mapping from each provider result into the application's policy. A qualifying result can proceed to the remaining document checks. A threat result stays blocked. An unsupported, missing or failed result stays unavailable while the service retries, requests another format or routes the case to an authorised reviewer.

Set a timeout for the user journey without turning that timeout into permission to release. The message can say that checking is delayed and explain the next action. It should not call the file malicious merely because a service failed to answer.

![Quarantine-first upload process: receive into restricted storage, check the exact object version, apply an explicit verdict policy, then release only the approved version. Missing, failed or unsupported scans remain unavailable.](https://cdn.hashnode.com/uploads/covers/60ecf4a0fc37a15ec15655e8/8e432ccb-d452-41df-bcf3-b20b476df9ae.png)

*Original infographic: SultanByte. Proposed release workflow informed by OWASP, AWS GuardDuty and Microsoft Defender for Storage documentation, October 2026. A qualifying scan is one control, not a guarantee that a document is safe or authentic.*

## Expect retries without repeated releases

[Amazon S3 event notifications](https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventNotifications.html) are designed for at-least-once delivery. AWS also warns that a worker writing into the same triggering location can create an execution loop. Keep incoming and released-object triggers distinct.

For this design, process events idempotently against the upload and version record. A duplicate qualifying verdict must not create another customer notification or replace a newer decision. Validate the event's origin and schema before allowing it to influence release state.

Handle late results deliberately. Suppose upload A is cancelled and a replacement B is accepted. A delayed result for A must not release B just because both share a display name. Similarly, a retry after deletion should not resurrect a file. Define cancellation and deletion as states the worker checks before taking action.

Add reconciliation for uploads that remain in checking without a usable result. Compare the pending records with the processing system and retry through a bounded path. Record the reason for intervention. This lets support distinguish an unsupported document from a permission problem without opening customer files to investigate routine failures.

## Make the regional decision about the whole pipeline

A local bucket alone does not describe where the upload goes. For each Saudi or UAE deployment, draw the actual route through malware analysis, document conversion, previews, OCR and support access. Include diagnostic destinations and retained copies in the review.

Microsoft states that its storage malware scanning operates in the storage account's region, while also describing limited sharing of file metadata for further analysis. That is a vendor statement about a specific service, not a conclusion about the rest of your product. Confirm current regional feature availability and your exact configuration before selecting it; the same documentation says not every region supports scanning.

Avoid a generic “MENA-compliant upload” claim. Give buyers a deployment-specific record of processing locations, access roles, retention and exception handling. Have the relevant specialists assess that record against the customer's obligations. This guide does not assert that the two countries have identical requirements or that either requires every uploaded file to remain in-country.

For founders, this review also exposes operating costs that a basic storage estimate misses. Budget for quarantine retention, scanning, retries and document processing. Choose product limits from expected workloads and test evidence rather than copying the largest file size a vendor advertises.

## Prove the release gate before launch

Use synthetic documents in a non-production environment and test the deployed permissions, not only a mocked worker. The following acceptance cases are a proposed test plan, not published benchmark results:

- While a scan is pending, try the ordinary download endpoint, preview path and direct object URL. None should disclose the document to an ordinary user.
- Deliver the same qualifying result twice. Require one release transition and one intended notification.
- Replace an upload while the earlier version is being checked. Prove that the earlier verdict cannot authorise the replacement.
- Return unsupported, access-denied, failed and missing-result cases. Require a truthful user status and no automatic release.
- Cancel or delete the upload, then deliver a delayed result. Confirm that the file stays unavailable.
- Remove scanner access in the test environment. Check the alert and recovery procedure without granting a broader application role as a workaround.
- Request a released document as another customer. The scan decision must not substitute for download authorisation.

Keep evidence of both the response and stored state. An error page is not enough if the object became readable through another route. Assign an owner to stale uploads and exceptional reviews before enabling the feature for customers.

The launch criterion is a demonstrated boundary: received documents remain restricted, a recorded decision refers to exact content, and ordinary access begins only through the approved release path. The progress bar can finish earlier. Access should not.