Can an Uploaded File Become Public Before Validation?

Keep uploads private until validation accepts an exact object version. Review replacement races, promotion authority and every serving path.

Upload success is not permission to serve the file

An upload can become retrievable before validation if a storage policy, application route, signed download link or delivery origin exposes it too early. A scanner running asynchronously does not close that gap. The serving boundary must deny unaccepted objects independently of whether scanning has started, finished or failed.

Consider a fictional customer-document service. A browser uploads a PDF, the application immediately shows a download link, and a worker scans the file later. Even if the worker eventually rejects it, someone may already have retrieved it. Moving the scanner earlier in a queue improves timing but does not change the fact that access was permitted before acceptance.

This article proposes an upload and promotion contract for that situation. All object identifiers and states are illustrative, not an Ampity security finding or a tested cloud deployment. The decision is when an exact artifact may cross a serving boundary. Malware detection, privacy classification and publication authorization remain separate questions, each requiring the controls appropriate to the application.

Quarantine needs an enforced access boundary

The OWASP file-upload guidance recommends layered validation, constrained file types and sizes, controlled storage and access. Define quarantine as an enforced denied-serving state. Naming a directory or object prefix quarantine does not restrict access.

Give the validation policy concrete checks. Specify allowed extensions and detected file types without trusting the uploader's Content-Type, maximum upload size, decompressed-size and parser-resource limits, and the required malware or content-disarm checks for that file class. A file signature or successful scan alone cannot satisfy the whole policy. Record unsupported and encrypted formats explicitly rather than interpreting an unavailable inspection as a pass.

Separate roles and paths. The uploader may place a new object in the intake area but must not update the accepted-artifact record or write to the delivery area. A validation worker reads intake objects with only the processing access it needs. A promotion role creates a serving artifact only from an accepted validation record. The delivery service reads only approved destinations, not arbitrary keys supplied by a browser.

AWS's S3 Block Public Access documentation describes controls against public access through policies and ACLs. Inspect effective permissions and actual delivery routes as well. A privileged application can still read an intake object and return it to an unauthorized visitor even when anonymous S3 access is blocked.

Test direct object access, application downloads, previews, thumbnails, signed links and the delivery origin. A private bucket used behind a permitted delivery service can still expose the wrong object through that service. A storage console's public-status indicator cannot establish what every application route allows. The boundary is the complete retrieval path, including its identity and object-selection checks.

Bind the verdict to bytes that cannot silently change

AWS's presigned upload documentation explains that an upload to an existing key replaces its current object. A key alone therefore cannot identify what was validated. If the uploader can change its contents, an earlier verdict cannot approve whichever bytes happen to be current later.

Presigned URLs are bearer capabilities: anyone holding a usable URL can exercise its signed permission. They can be used repeatedly until expiry or another effective restriction prevents access. Issuing an upload URL is not a one-time-write guarantee. Issue download URLs only after checking the accepted artifact and the caller's authority, and account for their continued usability after issuance. A short expiry reduces the exposure window but does not make each download consult current application state.

In the fictional sequence, intake key U17 first contains version V1. A worker validates V1. A later authorized upload creates different contents at the same key, V2. A naive promoter reads the current key and copies V2 while attaching the verdict for V1. The scanner may have worked correctly; the promotion path has associated its result with the wrong artifact.

This example uses versioning-enabled S3 general-purpose buckets. The S3 Versioning guide describes distinct version identifiers for new writes after versioning is enabled. Retain the actual identifier and select that version explicitly through validation and promotion. Existing objects can retain a null version ID when versioning is enabled, and suspended versioning has different write behavior. S3 directory buckets do not support this versioning pattern. Reject these cases from this contract or define and verify a separate identity-and-replacement control before accepting them. An application field called version cannot supply the missing storage guarantee.

Record upload identity, tenant or owner, source location, version, server-verified content digest, validation policy and verdict. A digest supplied by the uploader is a claim until the trusted processing path verifies it against the bytes it reads. The destination record must identify the exact served artifact too. Do not map a verdict for V1 to an unversioned latest-object lookup at delivery time.

S3 upload checksums can verify transfer integrity. Record the algorithm and whether the checksum covers the whole object or a composite upload. Do not assume every ETag is a full-file cryptographic digest. Matching checksums establish a byte-integrity check, not a malware, privacy or publication verdict.

Unique intake keys can reduce accidental replacement, but uniqueness alone does not prevent a permitted actor from rewriting the key. Either enforce the intended immutability or use a provider-supported version identity throughout the path. Protect against deletion or unavailable source versions as well. If the approved source cannot be retrieved reliably, promotion should stop rather than substitute another object with the same filename.

Treat promotion as a guarded state transition

Define the states and their serving permissions explicitly. Uploaded means received into private intake. Validating means checks are incomplete. Accepted means the specified artifact satisfied the named policy. Promoted means the approved delivery artifact is present and recorded. Rejected, failed and unknown are not aliases for accepted.

Use a readable acceptance worksheet to connect the storage and application records. The labels below describe an illustrative upload, not executable configuration. V1, V2 and D17 stand for actual identifiers returned by the trusted storage path.

For a copy-based implementation, S3 CopyObject selects the current source version unless the copy-source request specifies a version ID. Request the accepted source version explicitly. The destination receives its own version ID; do not reuse V1 as the destination identity. Check that destination versioning is enabled too, or establish a separately enforced destination identity contract before publishing.

This single-request CopyObject example assumes an object within the API's 5 GB copy limit. Larger objects require multipart copy and a separately reviewed completion, retry and recovery path. The same accepted-source and protected-destination identity requirements still apply.

A CopyObject HTTP 200 response can contain an embedded error. Read and handle the complete response, including the SDK's reported result or exception, before recording a successful copy. Keep failed, interrupted and uncertain copies out of serving state. A returned status code alone cannot establish that the approved destination exists.

A promoter checks the current authoritative acceptance record and claims the transition using concurrency controls suitable for its state store. It must not trust a browser field or an unrestricted storage tag that the uploader can alter. Keep repeated worker delivery idempotent around the accepted artifact identity. A duplicate completion event should not publish two different outputs or move a rejected object into serving state.

If replacing an upload retires the earlier request, a late V1 verdict must not revive that retired request. Version identity prevents serving the wrong bytes; current lifecycle and authorization checks prevent serving an artifact whose acceptance is no longer valid. Review both conditions at the protected transition.

Object creation and the application's state update may not be one transaction. Design the order so an incomplete update cannot expose an unaccepted object. A protected destination can be created first and remain unreachable through the application until the record is committed. If a crash leaves an orphaned destination, an owned reconciliation process can settle it without treating its mere existence as publication approval.

This approach relies on the destination being inaccessible through bypass routes and protected from unauthorized replacement. If the delivery origin can read every destination key regardless of state, the proposed application gate is not sufficient. Confirm the actual origin and cache behavior rather than assuming that the state record controls requests that never consult it.

Review the failure states, not only an accepted PDF

The five cases below are expected review decisions for an authorized rehearsal. They are not observations from a deployed storage system or a malware scanner.

Upload received; validation pendingDecision: Deny visitor retrieval and previewEvidence needed: Denial across direct, application and delivery routes

V1 accepted; current key now points to V2Decision: Never serve V2 under the V1 verdictEvidence needed: Explicit V1 promotion and protected destination identity

Scanner fails or returns an unknown outcomeDecision: Keep intake private; do not promoteEvidence needed: Owned retry or review path and a complete policy verdict

Protected D17 created; promotion record not committedDecision: Do not expose D17 through the applicationEvidence needed: Reconciliation of artifact identity and authoritative state

Exact artifact promoted; requester lacks its access rightsDecision: Deny this requesterEvidence needed: Tenant/owner scope and the intended publication audience

Make policy completeness explicit. A no-malware verdict is not proof that the file is an allowed type, within processing limits, free of confidential information or authorized for public release. Assign those checks to the required policy before setting accepted. Where the application intentionally keeps every document private, promoted means eligible for authorized delivery, not accessible to everyone.

Transforms create another artifact. A preview, sanitized PDF or extracted attachment may not have the same bytes as the source that passed a scanner. Define validation and provenance requirements for the derived output, and protect intermediate artifacts too. Do not let a thumbnail service become an alternate public route into private intake while the primary download route remains correctly blocked.

AI extraction must stay inside the same boundary

An AI document pipeline may need access to untrusted content before publication. That processing permission is narrower than serving permission. Isolate the parser and extraction worker with appropriate resource limits and access controls. Do not treat content inside an uploaded document as instructions to change recipients, fetch arbitrary URLs or publish another file.

Approve disclosure to any external scanner or AI service separately. Check the permitted data classes, processing location, retention and training terms, and which document content the service receives. Permission for an internal worker to inspect a file does not authorize sending it to a public scanning service or model provider. Use only the approved processing path; keep the file held when the required inspection cannot run within those limits.

Use the retrieved-instruction authority guide for that separate action boundary. An extraction model returning a sensible summary does not validate the file's safety or authorize disclosure. Model confidence is not a substitute for the upload policy's required checks, and malware scanning alone does not address hostile natural-language instructions.

OWASP's prompt-injection guidance includes instructions hidden in external files. Enforce tool permissions, outbound network restrictions and publication authority outside the model. Asking a model to ignore hostile instructions cannot guarantee that it will do so.

Validation has limitations. Unsupported formats, encrypted files and unavailable processing services may need a held state or an explicitly authorized alternative. Fail closed at the serving boundary while providing a useful status and a next step to the uploader. Do not keep people waiting indefinitely without an owner, a bounded retry policy and a reviewed retention or deletion path.

The proposed separate-artifact design does not apply unchanged to every storage provider or streaming application. Some systems can enforce a version-bound serving gate without copying; others require a different publication mechanism. Choose based on the actual access path and identity guarantees. Do not add a second bucket as a ritual if it does not create an enforceable security boundary.

Prove denial before approving publication

Start with an access-path inventory and harmless test files in an authorized environment. Ask which identities can upload, validate, promote, retrieve and alter state. Attempt retrieval before acceptance through each real route, then replace the intake object between validation and promotion. The expected result is denial for unaccepted content and delivery of only the exact approved artifact.

Include deliberately broken controls: a verdict stored against key alone, a promoter reading latest, an application that signs intake downloads before acceptance, and a preview route bypassing the state check. The rehearsal should detect each gap. A single successful scan of a benign PDF cannot prove that access remains denied during delays, failures or replacement races.

Add the following proposed acceptance cases before connecting real publication effects:

These are expected outcomes to measure, not results obtained for this article. Retain the actual fixture inputs and observer results when the implementation is rehearsed. A test report must distinguish a denied request, an uncertain copy and a missing observation.

Retain source and destination identities, policy version, decision evidence, denied-route results and the reviewer who accepted the boundary. Include revocation requirements if accepted artifacts later need to be withdrawn. Changing a database flag does not necessarily remove a cached copy or an already issued download capability. Treat those paths as a separate withdrawal review rather than promise instantaneous recall.

For what an extracted document actually proves, read the document evidence guide. A backend systems review can examine guarded transitions and concurrency, while a cloud security review can examine effective object permissions and delivery routes. Agree the actual scope and acceptance evidence before changing production access.

No upload, scanner execution, cloud-policy test or promotion race was executed for this article. If you choose to contact Ampity, share the upload route and the earliest point at which a visitor can currently retrieve the file, without disclosing private documents or live signed URLs.