Skip to content

How would you safely let an admin upload an event poster directly to S3?

1 min read · main part only; folded sections are optional

After this you can answer: How would you safely let an admin upload an event poster directly to S3?

Upload paths contain the event, authenticated admin and server-generated UUID. The browser does not choose a filename or arbitrary destination. The presigned request also requires AES256 server-side encryption. The accepted formats are PNG and JPEG, up to two MiB, 4096 pixels per side and sixteen million pixels.

Completion reads S3 metadata and bytes, binding the read to the object’s ETag. The later copy uses the same ETag condition, so replacing the upload between inspection and publishing fails rather than publishing unchecked content. A fresh published key means reusing the still-valid upload URL cannot overwrite the published poster.

Only after the copy succeeds does Postgres reference the published key. A later failure can leave an unattached object, which is preferable to a page referencing an unverified or missing one. For production, add an isolated scan and image re-encode step, cleanup of abandoned objects and resource limits around processing.

Does a matching Content-Type prove the file is safe?
No. It is caller-provided metadata. The service checks bytes too, but its header parser still does not prove the full image is valid or harmless.
What if the admin overwrites the upload during completion?
The ETag conditions bind inspection and copy to the same source content. A changed source is rejected, and the API asks for a fresh upload.
Why store the key rather than the URL?
The object key is durable. A signed URL expires and should be generated when needed; persisting it would make the poster disappear after its signing window.

Read S3 presigned urls, then inspect the ticket-assets-bucket piece →.

apps/api/src/services/posters.ts → complete

Compare the upload-CORS case.

Read this book online: https://book.theversehub.in/