file-upload-security

• SKILL.mdcore · 6,535 bytes
• SKILL.mdcore · 6,535 bytes
• metadata.jsonasset · 1,423 bytes
• references/direct-upload.mddoc · 3,112 bytes
• references/format-handling.mddoc · 4,597 bytes
• references/verifying-findings.mddoc · 3,517 bytes

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/file-upload-security/SKILL.md. -->

# File Upload Security

Accept, store, process, and serve user uploads safely: type-appropriate content validation, decompression limits, generated storage keys, quarantine before publication, isolated media processing, and scoped direct-to-storage credentials. Use when generating a file-upload endpoint, wiring presigned or SAS uploads to S3, GCS, or Azure Blob, processing user-supplied images or documents, or serving user-generated content.

## ALWAYS

- Put every new upload in a **non-public quarantine** location, and do not expose it, link it, index it, or hand it to a downstream workflow until validation has succeeded. Quarantine → validate → process → publish, in that order. This is the invariant the rest of these rules hang from, and the one direct-to-storage uploads most often skip.
- Validate content **server-side with checks appropriate to the format**. Where a format has a reliable signature, verify it; for container and document formats — DOCX, XLSX and ZIP are all ZIP at the container level — also validate structure against the format you expect. Text-based formats such as SVG and CSV have no signature to check at all, so a signature check alone is not a content policy. The client's `Content-Type` and the filename are attacker-controlled and are never the check.
- Keep a **per-endpoint allowlist** of accepted types and deny everything else. Deny `image/svg+xml` by default: an SVG is a document that can carry script. Where an endpoint genuinely requires SVG, treat it as active content — rasterize it, or run a maintained **SVG-aware** sanitizer with an explicit element, attribute, URL and CSS allowlist. A generic HTML sanitizer is the wrong tool for it.
- Bound the **expansion**, not only the upload. For archives and compressed or container formats, cap expanded bytes, entry count, nesting depth, compression ratio, per-entry size and processing time, and reject before extracting when the projected expansion exceeds policy. A limit on the compressed bytes says nothing about what they become (CWE-409).
- Store under an **application-generated identifier** — a UUID or content hash — outside the executable or web document root, and never build the storage path from the user-supplied name. Keep the original filename as bounded metadata only, and encode it for the specific output context where it is displayed. There is no "escaped at rest" that is safe in every context.