A municipal upload feature re-encodes images but still stores files under a web-accessible path with predictable names. What defense-in-depth guidance fits best?
Select an answer to reveal the explanation.
Short Explanation
Converting a photo is good — leaving it where the web server can run weird leftovers is not. Solid upload hygiene stacks re-encoding with off-webroot storage, random names, and no execution. A .jpg suffix is not a security control.
Full Explanation
Municipal upload features that re-encode images yet still store files under web-accessible paths with predictable names need defense-in-depth: re-encode content, store outside the webroot or behind controlled download handlers, randomize object names, and ensure the upload store cannot execute scripts.
Re-encoding alone does not make webroot storage and predictable names harmless—direct URL guessing and residual parser issues remain. Allowing executable Content-Types because a name ends in .jpg invites bypass. Disabling authentication on upload endpoints to simplify scanning expands abuse surface unacceptably.
Exam caveat: image re-encoding reduces some polyglot risks but is not a complete upload hardening program.
Operational check: upload a benign test image within RoE, inspect stored path and URL predictability and execution permissions, and verify whether objects are served as static non-executable content. Recommend object storage patterns suitable for civic document intake. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next release window that the same control still holds under the application's current auth model.