Separate MIME claims from actual upload bytes
Browser MIME and extensions are claims, not proof. A CMS image written to a public bind mount needs byte-signature checks and atomic publication before it becomes visible.
Table of contents
Browser MIME and extensions are claims, not proof. A CMS image written to a public bind mount needs byte-signature checks and atomic publication before it becomes visible.
Atomic publication
The content-console route checks an allowlisted MIME, size, and PNG/JPEG/WebP/GIF/AVIF signature. It writes an exclusive random temporary file in the same directory and renames it atomically, so the public container never reads a partial file. It records SHA-256 in bounded audit details without logging the original content.
Separate storage owners
This is intentionally separate from a user's sharp/private upload pipeline. Public CMS assets, private user files, and quarantine files have different storage, caching, and deletion owners.
Failure UX
| Validation point | Failure behavior |
|---|---|
| MIME and signature disagree | Remove the temporary file and do not publish |
| Size limit exceeded | Stop reading and explain the limit |
| Rename fails | Keep the existing public file and return a retryable state |
When a signature or size check fails, do not publish the file; explain supported formats, limits, and how to choose another file. Add a processor and quarantine/review state only when the product actually needs image decoding or resizing.
Related course: Validate and publish uploads atomically