file-upload-security

File Upload Security

User-uploaded files are one of the highest-leverage attack surfaces. A single endpoint that accepts * MIME types and writes to a server-served path is a path to RCE, XSS, SSRF, stored-XSS in PDFs, and a half-dozen other failure modes. The defaults of every web framework do less than they should — this skill is what to add on top.

Generic, not CMS-specific. For Payload-specific tuning see payload-cms-security. For WordPress see wordpress-hardening. For storage choice / backend architecture see backend-architecture.

When to invoke

• Adding file upload to an endpoint for the first time
• A user-uploaded file caused or contributed to an incident
• Migrating from local-disk uploads to object storage (R2 / S3 / Spaces)
• Reviewing an existing upload feature you inherited
• Adding new file types (e.g. previously images only, now PDFs too)

The threat model

A user can upload anything labeled as anything. From your perspective:

• The filename is attacker-controlled — ../../etc/passwd, 🔥.jpg.exe, index.html
• The Content-Type header is attacker-controlled — JPG bytes claiming to be application/json, executable bytes claiming to be image/png
• The file extension is attacker-controlled
• The file contents may be a polyglot — bytes that are valid as image and valid as HTML / JavaScript / PHP

Defense: trust nothing the client says about the file. Inspect the bytes, re-derive the type, generate your own key for storage, serve from an origin that cannot execute anything.

Step 1 — Validate at the boundary

Size limits, server-side

import multer from 'multer';

const upload = multer({
  storage: multer.memoryStorage(),
  limits: {
    fileSize: 10 * 1024 * 1024,    // 10 MB hard cap
    files: 5,
    fields: 20,
    fieldSize: 1024,
    fieldNameSize: 100,
  },
});

app.post('/api/upload', requireAuth, upload.single('file'), async (req, res) => {
  if (!req.file) return res.status(400).json({ error: 'no file' });
  // ... continue with content validation
});