Multer's default file size limit is unlimited, and that's not a typo

Multer is the middleware nearly every Express app reaches for the moment it needs to accept a file upload. The quickstart example in its own README looks like this:

const multer = require('multer')
const upload = multer({ dest: 'uploads/' })

app.post('/profile-photo', upload.single('avatar'), (req, res) => {
  res.json({ path: req.file.path })
})

Five lines, works immediately, and it's the version that ends up in production because nothing about it looks wrong. It isn't wrong, exactly. It's incomplete in a way that only matters once someone sends it a file you weren't expecting.

There is no default size limit

Multer's limits option accepts a fileSize in bytes, and if you don't set one, there isn't one. Not a generous default, not a sane fallback, nothing. A client can POST a ten gigabyte file to that endpoint and multer will happily start writing it to uploads/ or buffering it in memory, depending on your storage engine, until either the disk fills up or the process runs out of memory.

This is easy to miss in testing because you're the one sending the requests, and you're sending a 200KB profile photo like the feature is supposed to receive. Nothing about local development exercises the path where someone sends something else.

Memory storage makes it worse, faster

If you're using multer.memoryStorage() instead of disk storage, because you want to stream the upload straight to S3 or process it before saving, the unlimited file goes straight into your process's memory as a Buffer. Disk storage at least fails in the relatively survivable way of running out of disk space on a machine that keeps running. Memory storage with no size cap can OOM-kill your entire process from a single request, taking down every other request it was handling.

Setting the limits that should have been the default

const upload = multer({
  dest: 'uploads/',
  limits: {
    fileSize: 5 * 1024 * 1024, // 5MB
    files: 1,
  },
})

fileSize caps the individual file, files caps how many files a single multipart request can include, since a client can attach a large number of small files to the same request just as easily as one large one. Pick numbers based on what the feature actually needs. A profile photo endpoint has no legitimate reason to accept a 5GB upload, so don't leave the door open for one.

Handle the rejection, not just the limit

Setting fileSize isn't quite the end of it. When multer rejects an oversized upload, it does so by emitting a MulterError with code LIMIT_FILE_SIZE, and if nothing in your error-handling middleware checks for that, Express's default error handler turns it into a generic 500 with a stack trace in the response body:

app.use((err, req, res, next) => {
  if (err instanceof multer.MulterError && err.code === 'LIMIT_FILE_SIZE') {
    return res.status(413).json({ error: 'File too large' })
  }
  next(err)
})

A 413 with a clean message tells the client what actually happened. A 500 with a stack trace tells an attacker something about your stack, and tells your legitimate user nothing useful at all.

This isn't unique to multer

The same pattern shows up in busybox, formidable, and most other Node upload libraries: the size cap is opt-in, not opt-out. It's a reasonable design choice for a general-purpose library that doesn't know your use case, but it means the responsibility for picking a sane limit sits entirely with whoever wires it up, and it's exactly the kind of configuration detail that's invisible until someone hits it on purpose.

Seaworthy checks upload middleware configuration for missing size limits, since this is one of the more common gaps between what a demo needs and what a production endpoint accepting arbitrary input actually requires.