All posts

June 10, 2026 · 4 min read

If Your App Lets People Upload Files, Here's What to Check in the Next 15 Minutes

File uploads show up everywhere: profile pictures, document attachments, CSV imports, resumes. Almost every one I've looked at has a form that appears to restrict what can be uploaded. The gap I keep finding is between that appearance and what the server actually enforces once the file arrives.

Why the frontend check isn't the real check

A file picker that only shows image files, or a dropdown that says "accepted formats: PDF, DOCX," is a convenience for the user, not a security control. Anyone can bypass it entirely: rename a file's extension, use a direct API call instead of the form, or edit the request before it's sent. If the actual restriction lives only in the browser, it isn't a restriction at all.

What to actually test

  • Rename a file you're not supposed to be able to upload, giving it an allowed extension, and see if the server accepts it anyway based on the name alone.
  • Check whether the server verifies the file's actual content type, not just its stated extension or the browser-reported MIME type, which the uploader controls.
  • Try uploading a file that's far larger than seems reasonable for the feature, and see whether there's an actual size limit enforced server-side, not just a slow browser warning.
  • If uploaded files are ever served back out, check whether they're served from a location that could let an uploaded file execute as code rather than just being downloaded as data.
  • Check whether uploaded files are scanned for anything at all, or simply accepted and stored as-is.

Why this one is easy to miss when building fast

An upload feature usually gets built to solve the immediate problem: let a user attach a file, store it, show it back to them later. The validation layer is the part that gets added "later," and later doesn't always arrive, especially when the feature was scaffolded quickly and looked like it worked the first time it was tested with a normal file.

The fix, and why it belongs on the server

Every meaningful check, file type, size, and content, needs to happen on the server, using the actual bytes received, not information the client claims about itself. The frontend restriction is still worth keeping, it's a better experience for a normal user who picks the wrong file by mistake, but it should never be the only line of defense.

If your app accepts uploads anywhere, this is a fifteen-minute test worth running today: try to upload something you shouldn't be able to, and see what actually stops you.

Related reading

Harbova is a security service for apps built with AI tools. Start with a free scan, and if it finds something serious, we can fix it and prove it is closed.