Secure uploads and downloads

Secure Upload & Download

User-uploaded files are untrusted binary inputs that can carry active scripts (XSS via SVG/HTML), path traversal payloads, decompression bombs, SSRF vectors or malware. Enforce defense in depth at both ingress (upload) and egress (download/preview).

1. Untrusted Input Validation (Beyond Extensions)

• Never trust File.name extension or the client's Content-Type header:
  • Inspect magic bytes (file signatures) from the first chunk of the actual uploaded bytes (e.g., file-type / libmagic) and verify that the detected format matches the allowed allowlist for that feature.
  • For images, decode headers/dimensions with a battle-tested parser before accepting.
• High-risk formats:
  • SVG, HTML, XML, XHTML, SWF: contain executable JavaScript (<script>, onload=, foreignObject) and XXE vectors. Never allow raw SVG/HTML as user avatars or inline images served from the application origin; rasterize to PNG/WebP/AVIF or sanitize and serve only as an attachment from a sandboxed domain.
  • Archives (.zip, .tar.gz, .docx, .xlsx): enforce strict Zip Slip path validation (path.resolve(destDir, entryName).startsWith(destDir + path.sep)), reject symlinks, and cap total uncompressed byte count, compression ratio and file count to prevent zip bombs.
• Remote URL imports (SSRF Prevention):
  • If users can import files by URL, block private/loopback/link-local/cloud-metadata IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.169.254, IPv6 ::1, fc00::/7, fe80::/10) at DNS resolution and socket connection time, disable redirects to internal hosts, and enforce strict byte and timeout limits.

2. Resource-Level Authorization & Presigned URLs

• Verify tenant & resource permissions on every operation: check that the authenticated user is authorized to upload to, view, share or delete the target parent resource (project, task, message, invoice) before issuing a signed URL or streaming bytes.
• Scoped Direct-to-Object-Store Uploads:
  • Never expose bucket-wide credentials to the browser.
  • Issue short-lived presigned PUT or POST policies (e.g., 5–15 minutes) locked to a single server-generated object key, exact Content-Type and Content-Length / content-length-range.
• Signed Download URLs Are Bearer Tokens:
  • Remember that a presigned S3/Blob GET URL cannot be individually revoked once issued until its TTL expires. Keep signed download URL TTLs short (e.g., 60–300 seconds) and generate them on demand after checking current authorization, or proxy through an authenticated edge/application endpoint when instant revocation is required.

3. Safe File Serving & Browser Execution Isolation

When serving user files back to browsers:

• Always set X-Content-Type-Options: nosniff so the browser never guesses executable HTML/JS from a text or image payload.
• Serve from an isolated origin/bucket domain (e.g., files.example-usercontent.com) separate from the main application origin so an inline file can never read application cookies, localStorage or CSRF tokens.
• Force Content-Disposition: attachment; filename="..."; filename*=UTF-8''... for downloads and any file type not explicitly safe for inline rendering, and apply Content-Security-Policy: sandbox on file responses.