file-upload-securitylisted

# 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`](../payload-cms-security/SKILL.md). For WordPress see [`wordpress-hardening`](../wordpress-hardening/SKILL.md). For storage choice / backend architecture see [`backend-architecture`](../backend-architecture/SKILL.md). ## 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