File Uploads: Ship User-Generated Content Without Burning Down Your Server

⬅️ Growth Overview

File Upload Strategy for Your New SaaS

Goal: Ship a file upload flow customers actually trust — direct-to-storage uploads with presigned URLs (not through your app server), strict file-type and size validation, optional image processing, virus scanning where required, signed-URL delivery for private files, and a per-tenant storage usage model. Avoid the failure modes where founders proxy 100MB files through their Node app server (memory crash), accept any file type (RCE risk), serve uploads from public buckets (privacy violation), or bill nothing for storage that grows linearly forever.

Process: Follow this chat pattern with your AI coding tool such as Claude or v0.app. Pay attention to the notes in [brackets] and replace the bracketed text with your own content.

Timeframe: Direct-to-storage uploads + basic validation in 2-3 days. Image processing + virus scanning + signed-delivery in week 1. Quotas + admin tooling + audit in week 2. Quarterly review baked in.

Why Most Founder Upload Flows Are Broken

Three failure modes hit founders the same way:

• Proxy uploads through the app server. Founder writes app.post('/upload', upload.single('file'), handler). Customer uploads a 100MB video. The Node process loads it into memory; the server crashes; uploads fail across the fleet for 5 minutes. Or worse: a malicious client uploads a 5GB file and the server runs out of disk processing it.
• Accept any file type. Founder allows uploads "to be flexible." Customer uploads a .svg with embedded JavaScript. Your image preview renders the SVG; the script runs in another customer's browser; you're shipping XSS. Or: customer uploads a .html file; you serve it from your domain; same-origin attacks follow.
• Public bucket for "convenience." Founder makes the S3 bucket public to skip signed URLs. Six months later, someone Googles site:s3.amazonaws.com for the bucket and finds 500K files including private medical records. Privacy regulator becomes involved.

The version that works is structured: client uploads directly to object storage via presigned URL, file type and size validated server-side before signing, virus-scanned async before becoming "available," served via signed URLs with short TTLs, and quota-tracked per tenant.

This guide assumes you have already done Authentication (uploads are user-scoped), have shipped Multi-Tenant Data Isolation (uploads are workspace-scoped), have considered File Storage Providers (S3 / R2 / Vercel Blob / etc.), and have Audit Logs for high-value upload events.

1. Decide What You're Allowing

Before writing code, decide what file types and sizes your product actually needs. The smaller the surface, the smaller the attack surface.

Help me decide the upload surface for [my product].

The decisions:

**1. Allowed file types**

Define an explicit allowlist (NOT a denylist). Common categories:

- **Images**: `.jpg`, `.jpeg`, `.png`, `.webp`, `.gif`, `.heic`, `.avif` — most products
  - Skip `.svg` unless you specifically need it AND you sanitize (strip <script>, <foreignObject>, etc.)
- **Documents**: `.pdf`, `.docx`, `.xlsx`, `.csv`, `.txt`, `.md`
  - PDFs can contain JavaScript; treat as untrusted
  - Office formats can contain macros
- **Video**: `.mp4`, `.mov`, `.webm` — only if your product uses video
- **Audio**: `.mp3`, `.wav`, `.m4a`, `.ogg`
- **Archives**: `.zip`, `.tar.gz` — be careful (zip bombs)
- **Code / config**: `.json`, `.yaml`, `.toml` — for IaC / config products
- **NEVER allow**: `.exe`, `.bat`, `.sh`, `.html`, `.js`, `.htm`, `.dll` — these have no legitimate use case in most SaaS

**2. Maximum file size**

Pick a number. Document it. Enforce it everywhere.

- Profile photos: 5 MB
- Document attachments: 25 MB
- General uploads: 100 MB
- Video: 1-2 GB (with chunked upload)
- Whatever the number, enforce it at:
  - Browser (`<input accept="..." max-size="...">`)
  - Server (during presign)
  - Object storage (CORS / size limit)

**3. Storage backend**

Per [File Storage Providers](https://www.vibereference.com/cloud-and-hosting/file-storage-providers):
- AWS S3 — default; mature; expensive egress
- Cloudflare R2 — S3-compatible; zero egress fees; great for indie SaaS
- Vercel Blob — bundled with Vercel; convenient
- Backblaze B2 — cheapest egress
- Supabase Storage — bundled if you use Supabase

**4. Public vs private by default**

DEFAULT TO PRIVATE. Add public-by-explicit-opt-in if needed (e.g., user avatars on a public profile).

**5. Per-tenant quotas**

- Free tier: 100 MB
- Paid tier: 10-50 GB depending on price
- Enterprise: custom
- Quota matters for unit economics (storage isn''t free) AND product (limits create upgrade pressure)

For my product, decide:
- The allowlist (be conservative; expand later)
- The size limit (per type if needed)
- The storage backend
- The public/private default
- The per-tenant quota

Output:
1. The allowed-types config
2. The size-limit config
3. The chosen storage backend with reasoning
4. The default privacy setting
5. The quota table per tier

The single biggest unforced-error: a permissive allowlist. Start strict; loosen only when a customer asks for a specific need. A 5-format allowlist is more defensible than a 25-format one when the security team asks "why does your product accept .ps1 files?"

2. Use Presigned URLs (Direct-to-Storage)

Don't proxy uploads through your app server. Generate a presigned URL; have the client upload directly to storage.

Help me design the presigned-URL upload flow.

The pattern:

**Phase 1: Request signed URL (small HTTP call to your server)**

1. Client requests upload: `POST /api/uploads/presign` with `{ filename, content_type, size }`
2. Server validates:
   - User authenticated and authorized
   - File type in allowlist
   - File size within limit
   - Workspace under quota
3. Server generates a unique storage key: `workspaces/{workspace_id}/uploads/{uuid}/{filename}`
4. Server creates a record in `uploads` table with status `pending`
5. Server creates a presigned PUT URL with:
   - Expiration: 5-15 minutes
   - Required Content-Type header (matches what client said)
   - Required Content-Length max (matches size limit)
6. Server returns: `{ upload_id, presigned_url, fields, expires_at }`

**Phase 2: Direct upload (client → object storage)**

7. Client uploads directly to the presigned URL
8. Object storage validates the headers match
9. Storage returns success
10. Client notifies your server: `POST /api/uploads/{upload_id}/complete`

**Phase 3: Confirm and process**

11. Server verifies the file exists in storage (HEAD request to S3/R2)
12. Server verifies the actual file size and MIME type
13. Server updates the upload record to status `uploaded`
14. Server enqueues post-processing jobs (virus scan, image resize, etc.)
15. After processing: status changes to `available`

**Schema**:

```sql
CREATE TABLE uploads (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  workspace_id UUID NOT NULL REFERENCES workspaces(id),
  uploaded_by UUID NOT NULL REFERENCES users(id),
  storage_key TEXT NOT NULL UNIQUE,         -- the S3/R2 key
  storage_backend TEXT NOT NULL,             -- 's3', 'r2', 'vercel-blob', etc.
  filename TEXT NOT NULL,                    -- original filename
  content_type TEXT NOT NULL,                -- declared MIME
  content_type_verified TEXT,                -- detected MIME (after upload)
  size_bytes BIGINT NOT NULL,
  status TEXT NOT NULL DEFAULT 'pending',    -- pending / uploaded / processing / available / quarantined / deleted
  scan_status TEXT,                          -- 'clean' / 'infected' / 'unknown'
  scan_result TEXT,
  is_public BOOLEAN NOT NULL DEFAULT FALSE,
  attached_to_type TEXT,                     -- 'message', 'profile', etc.
  attached_to_id UUID,
  expires_at TIMESTAMP,                       -- for the presigned URL window
  created_at TIMESTAMP NOT NULL DEFAULT NOW(),
  uploaded_at TIMESTAMP,
  processed_at TIMESTAMP,
  deleted_at TIMESTAMP
);
CREATE INDEX idx_uploads_workspace ON uploads(workspace_id) WHERE deleted_at IS NULL;
CREATE INDEX idx_uploads_pending ON uploads(status, created_at) WHERE status IN ('pending', 'uploaded', 'processing');

Critical implementation rules:

1. Never accept the file through your server. Even for "small" files. The pattern is the pattern.
2. Re-validate after upload. What the client said the file is and what it actually is may differ.
3. Use Content-Type and Content-Length conditions in the presigned URL so storage rejects mismatches.
4. Generate unique storage keys that don''t collide and don''t leak structure.
5. Short presigned-URL expiration (5-15 min). Long-lived URLs are forge-resistance hazards.

Don''t:

• Use predictable storage keys (upload-1, upload-2...) — guessable
• Trust the client''s claimed content_type for security decisions
• Allow the client to specify the storage key
• Skip the post-upload verification step

Output:

1. The uploads schema migration
2. The presigning endpoint code
3. The upload-complete endpoint code
4. The CORS config for the storage bucket
5. The client SDK / fetch code

The single biggest performance win: **direct-to-storage uploads.** A 100MB file upload that goes through your server takes 100MB of memory and locks an HTTP connection for the duration. The same file uploaded to R2 / S3 directly costs your server <1KB of data and <100ms of CPU time. Same outcome, 1000× cheaper.

---

## 3. Validate File Type Server-Side

The client tells you what type the file is. Don''t believe it.

Design the server-side type validation.

The pattern:

Layer 1: Extension check (cheap, first line)

• Reject if extension not in allowlist
• A .html file with Content-Type: image/png should still be rejected on extension

Layer 2: Magic-byte sniffing (after upload, before marking available)

• Read first ~16 bytes of the file
• Compare against known magic bytes for the declared type
• Use a library: file-type (Node), python-magic (Python), mime (Go)
• Reject if the actual content doesn''t match the declared type

Layer 3: For images, parse the metadata

• Use sharp (Node), Pillow (Python), or equivalent to parse
• Extract width, height, color profile
• If parsing fails: it''s not really an image; reject

Layer 4: For SVGs (if you must allow)

• Sanitize with DOMPurify or svg-sanitizer
• Strip <script>, <foreignObject>, <image href="javascript:...">, event handlers
• Or: don''t allow SVG. The simpler default.

Layer 5: For PDFs

• Acknowledge they can contain JavaScript
• Strip with qpdf --linearize --decrypt or similar before serving
• Or: render PDFs server-side as images for preview, deliver original only on explicit download

Layer 6: For Office documents (.docx, .xlsx, .pptx)

• They''re ZIPs with XML inside; can contain macros
• Strip macros if you process; warn customers if you allow them through

The magic-byte mismatch case:

• Client says image/png; actual bytes are GIF
• Could be benign (browser auto-detection) or malicious (extension confusion)
• Conservative: reject; require client to use the matching type

The extension-vs-MIME mismatch case:

• File named photo.png with content_type text/html
• Either fix is bad in production; reject

Don''t:

• Trust the client''s declared content_type for security decisions
• Skip magic-byte verification ("we trust our clients")
• Allow .svg without sanitization
• Allow archives (.zip) without zip-bomb protection (limit decompressed size)

Image-specific risks:

• Polyglot files: a file that''s valid as both image and HTML
• Pixel-flood DoS: 100MB JPEG that decodes to 100GB pixel buffer (use libvips / sharp limits)
• EXIF metadata leakage: GPS coordinates in photo metadata (strip on upload if privacy-sensitive)

Output:

1. The validation function with all 6 layers
2. The magic-byte library choice
3. The image-decoder limits
4. The SVG sanitization (or rejection) logic
5. The audit log for rejected uploads

The single biggest CVE category from upload features: **type confusion**. A file that the client calls a PNG, the server stores as a PNG, but is actually HTML — served back, it executes as HTML in another user''s browser. Every step in the pipeline must agree on what the file is, and disagreements are bugs (or attacks).

---

## 4. Scan for Malware Where Required

Some products need virus scanning; some don''t. Decide based on use case and compliance.

Decide whether you need virus scanning.

You need virus scanning when:

• Files are shared between users (one user''s upload becomes another''s download)
• Customers in regulated industries (healthcare, finance, government) demand it
• You handle email attachments
• You handle public uploads (any-user-uploadable)

You probably don''t need virus scanning when:

• Files are only ever consumed by the uploader themselves (private screenshots, etc.)
• All file types are images that you re-encode (re-encoding strips embedded threats)
• Compliance doesn''t require it

Implementation options:

Option 1: ClamAV (free, OSS, self-hosted)

• Install ClamAV on a worker
• Async scan after upload
• File status moves: uploaded → scanning → clean (or quarantined)
• Pros: free; on-prem
• Cons: you maintain it; signature DB is older than commercial

Option 2: VirusTotal / commercial scanners

• Send file hash; if known, get verdict
• For unknown files: upload (privacy implications) or self-host scanner
• Pros: better signatures
• Cons: cost; privacy

Option 3: Cloudflare R2 + scanner integration

• Some object storage offers scanning add-ons
• Check provider; rates apply

Option 4: AWS Macie / GuardDuty

• AWS-native scanning of S3 uploads
• Real-time
• AWS-only

The async-scan flow:

1. File uploaded; status uploaded
2. Worker picks up the upload; downloads it (or scans in-place)
3. Scanner returns clean / infected / unknown
4. Clean: status → available
5. Infected: status → quarantined; delete file from storage; alert security
6. Unknown: depends on policy (usually delete to be safe)

During scan, file is NOT available:

• Don''t serve files in uploaded or scanning state
• UI shows "Processing..." with a polling check
• Once available, normal access

Critical rules:

1. Async, not inline. Scanning takes seconds; don''t block uploads.
2. Quarantine, don''t silently delete. Keep the file in a quarantine bucket for forensics.
3. Notify the uploader. "Your upload was rejected because it failed our virus scan."
4. Audit every scan. Especially failures.

Output:

1. The virus-scanning decision (yes/no/per-file-type)
2. The chosen scanner
3. The async-scan worker code
4. The quarantine flow
5. The customer-facing notification

The biggest reputational hit: **a malicious file shared between users via your platform.** Even if your code didn''t execute it, your platform was the carrier. Scan for the use cases where it matters; don''t bother for the ones where it doesn''t.

---

## 5. Process Images Server-Side

If you allow image uploads, process them. Re-encoding strips threats; resizing saves bandwidth; thumbnails save reads.

Design the image processing pipeline.

The pattern:

After a file is uploaded and verified as an image:

1. Use libvips / sharp / Pillow to decode
2. Strip metadata (EXIF, IPTC) unless you need it
3. Re-encode to canonical format (JPEG for photos, WebP/AVIF for modern, PNG for transparency)
4. Generate variants:
   • Thumbnail (e.g., 200×200) — for list views
   • Display (e.g., 1200px max) — for detail views
   • Original — only for export / explicit download
5. Store all variants alongside the original
6. Mark upload as available

Variant naming convention:

• original/{key} — the original file
• display/{key} — display-sized
• thumb/{key} — thumbnail
• All under the same workspace/upload UUID

Processing constraints:

1. Limit input pixel count. A 100MB JPEG can decode to a 100GB pixel buffer if dimensions are huge. Limit to ~50MP.
2. Limit memory. libvips streams; sharp has memory caps. Set them.
3. Run in workers. Image processing is CPU-heavy; don''t do it in the request handler.
4. Idempotent. Re-running the job for the same upload should produce the same variants (or skip).

Format choices:

• Photos: JPEG (universal, well-compressed) or WebP (smaller, modern)
• Graphics with transparency: PNG or WebP
• Modern best: AVIF (smaller still; less universal)
• Strategy: serve WebP/AVIF with JPEG/PNG fallback via <picture> tag

EXIF metadata:

• Strip by default (privacy: GPS, camera info)
• Keep selectively: orientation (so images display right-side-up)
• Document the policy in your privacy notes

Don''t:

• Process inline in the upload request
• Trust the original file as the display version (re-encode for safety)
• Ship the original to the user without explicit need (bandwidth hog)
• Skip EXIF stripping for user-shared photos

Output:

1. The image-processing worker code
2. The variant naming convention
3. The pixel-count and memory limits
4. The EXIF-stripping policy
5. The format-selection strategy with <picture> markup

The biggest performance win for products with images: **serving thumbnails for list views.** Loading 100 full-size images on a list page kills mobile UX. Thumbnails are 1/100th the size; users never know.

---

## 6. Serve via Signed URLs

Don''t expose object-storage URLs directly. Sign them; expire them.

Design the signed-URL delivery.

Public files (e.g., user avatars on a public profile):

• Stored in a CDN-cached path
• Served via your CDN (Cloudflare, CloudFront, Vercel CDN)
• Cache-Control: public, max-age=31536000 (long cache)
• Optionally signed but generally OK as public URLs

Private files (default for most uploads):

• Stored with private ACL on the bucket
• Served via signed URLs:
  1. Client requests GET /api/uploads/{id}/url
  2. Server checks authorization (user has access to this upload)
  3. Server generates signed URL (typical TTL: 5 minutes)
  4. Client uses the signed URL to fetch the file
• The signed URL is short-lived; even if leaked, expires

Signed-URL design:

• TTL: 5 minutes for download; 1 hour for embedded display
• Re-fetch when expired (client refreshes its URL)
• Per-user signing: include user_id in the signature so logs can attribute

For embedded files (image src in HTML/email):

• Generate signed URL with longer TTL (e.g., 24 hours)
• Or: use a proxy endpoint that fetches and serves the file (your app authenticates; storage returns to you)
• Trade-off: longer TTLs are simpler but riskier; proxy is heavier on your servers

Critical implementation rules:

1. Authorize before signing. The signing endpoint is the auth gate.
2. Don''t cache signed URLs across users. Each user gets their own.
3. Audit access. Log every signing event for high-sensitivity files.
4. Use S3 / R2 / Vercel signed URLs, not custom token systems.

Don''t:

• Make buckets public to "skip signing" (the classic data-leak)
• Use very long signing TTLs (forge-resistance hazard)
• Sign on every request without caching the URL client-side
• Skip authorization on the sign endpoint

Output:

1. The sign-URL endpoint code
2. The authorization check
3. The TTL policy per file class
4. The audit log integration
5. The CDN config for public files

The single most-common upload data leak: **publicly accessible buckets that should have been private.** Default to private; require an explicit reason to make any path public; audit bucket-level public access regularly.

---

## 7. Track Usage and Enforce Quotas

Files grow forever. Quotas align cost with revenue.

Design quotas.

The pattern:

Track per workspace:

• Total bytes uploaded
• File count
• Bandwidth served (egress)

Schema additions:

ALTER TABLE workspaces
  ADD COLUMN storage_bytes BIGINT NOT NULL DEFAULT 0,
  ADD COLUMN storage_quota_bytes BIGINT NOT NULL DEFAULT 0;  -- 0 = unlimited or use plan default

-- Optional: roll-up table for periodic snapshots
CREATE TABLE workspace_storage_snapshots (
  workspace_id UUID NOT NULL REFERENCES workspaces(id),
  snapshot_date DATE NOT NULL,
  storage_bytes BIGINT NOT NULL,
  file_count INT NOT NULL,
  bandwidth_bytes_30d BIGINT NOT NULL,
  PRIMARY KEY (workspace_id, snapshot_date)
);

Counter management:

• Increment on upload completion
• Decrement on file deletion
• Periodically reconcile against actual storage (catches drift)

Enforcement points:

1. At presign time: if quota exceeded, reject with clear error
2. On the upload form: show current usage and remaining quota
3. Monthly reconciliation: compare counter to actual storage; alert on drift

Quota tiers:

• Free: 100 MB
• Pro: 50 GB
• Business: 500 GB
• Enterprise: custom
• Per Pricing Strategy: pick limits that align with unit economics

Quota-exceeded UX:

• Soft warn at 80% used
• Hard block at 100%
• Clear upgrade path: "You''re at 100% of free-tier storage. [Upgrade] or [delete files]."
• Don''t silently fail uploads; explain why

Bandwidth quotas (advanced):

• For products with many downloads, serving cost matters
• Track per-workspace egress bytes
• Throttle or block past tier limits
• Most products skip this in v1

Don''t:

• Track storage in a column updated on every upload (hot row contention) — use queue / async
• Forget to decrement on deletion
• Allow workspaces to silently exceed quota (kills your unit economics)

Output:

1. The quota tracking schema
2. The counter-update logic
3. The presign-time quota check
4. The reconciliation job
5. The quota-exceeded UI

The single most-overlooked detail: **quota reconciliation.** Counter columns drift over time. A monthly job that compares the counter to actual storage usage catches bugs that would otherwise go silent. Without reconciliation, your billing is off and you don''t know.

---

## 8. Handle Deletion Properly

Files persist long after the row that referenced them. Delete properly.

Design the deletion flow.

The pattern:

When a customer deletes a file:

1. Mark deleted_at = NOW() in your DB (soft delete)
2. Hide from the UI immediately
3. Decrement workspace storage counter
4. After grace period (e.g., 30 days):
5. Delete file from object storage (the actual bytes)
6. Hard-delete the DB row

When a customer deletes a parent (workspace, project, account):

• Cascade soft-delete to all uploads
• Or: query uploads by parent at the deletion job

The orphan-file problem:

Common bugs:

• Upload succeeds but the user navigates away before submitting; the file is never linked
• Upload succeeds but linked record fails to save; file is "linked to nothing"
• Workspace deleted but cascade missed some uploads

Solution: garbage-collection job

Daily job:

• Find uploads with created_at < NOW() - 24h AND attached_to_id IS NULL AND status != 'available'

• Delete from storage

• Mark in DB

• Find uploads where their parent is deleted

• Delete from storage

• Mark in DB

File-storage deletion specifics:

• S3 / R2 deletes are async; the bytes go away "soon" not "now"
• For compliance (right to be forgotten per Account Deletion & Data Export): document the deletion SLA
• Verify deletion completion before claiming "your file is deleted"

Critical rules:

1. Soft delete first. Hard delete is irreversible; soft delete gives 30-day undo.
2. Run garbage collection. Without it, storage costs grow unboundedly.
3. Audit deletions. Especially admin-initiated ones.
4. Document compliance retention. Some regulations forbid deletion (legal holds).

Don''t:

• Hard-delete immediately on customer click (regret window)
• Forget to delete from storage when soft-deletion ages out
• Run garbage collection without dry-run first (deleting too aggressively is hard to recover)

Output:

1. The soft-delete + grace-period flow
2. The garbage-collection job
3. The orphan-cleanup job
4. The audit-log integration
5. The deletion-SLA documentation

The biggest billing surprise: **a workspace that deleted "everything" but their storage bill keeps growing.** Files stayed in S3 because the cascade missed them. Garbage collection catches this; without it, you pay forever for data that was supposed to be gone.

---

## 9. Audit and Monitor

Uploads are high-value events. Audit and monitor them.

Design the audit and monitoring.

Audit events (per Audit Logs):

• upload.created — when the upload row is created
• upload.completed — when the file is uploaded to storage
• upload.scan_failed — when virus scan rejects
• upload.access_signed — when a signed URL is issued (sample at high volume)
• upload.deleted — when soft-deleted
• upload.permanently_deleted — when hard-deleted
• upload.quarantined — when scanner flags

Metrics to track:

• uploads.created_count — uploads per minute
• uploads.size_bytes — distribution of upload sizes
• uploads.completion_rate — % of presigned uploads that complete (low rate = client errors or aborts)
• uploads.scan_infected_count — scanner hits per period
• uploads.processing_duration — how long post-upload processing takes
• uploads.storage_bytes_total — overall storage consumption
• uploads.bandwidth_bytes_egress — overall serving bandwidth

Alerts:

• Sudden spike in upload volume (possible abuse / bot)
• Sudden spike in size_bytes p99 (someone testing limits)
• High infected-scan rate (active attack)
• Storage growing 2x normal rate (workspace abuse)
• Failed completion rate > 10% (probably a bug)

Customer-facing storage UI:

• Show current usage with bar / percentage
• List of largest files (so customer can clean up)
• Activity feed: recent uploads, deletions
• Export option for tax / compliance

Don''t:

• Log every upload at INFO level (too noisy)
• Skip the metrics dashboard
• Forget to alert on quota-exceeded events for paying tiers (bills surprise)

Output:

1. The audit event schema
2. The metric emission code
3. The alert rules
4. The customer-facing storage page

---

## 10. Quarterly Review

Storage and uploads rot. Quarterly review keeps them healthy.

The quarterly review.

Storage health:

• Total storage used vs revenue: are we losing money on free tier?
• Largest workspaces by storage: any abuse patterns?
• Egress bandwidth costs: trending?
• Orphan files cleaned up by GC: is the count growing or stable?

Upload patterns:

• Most-uploaded file types — does the allowlist still match real use?
• Average upload size trending up or down?
• p99 size — are users bumping the limit?
• Failed upload rate — what''s the cause?

Security review:

• Any new CVEs in image processing libraries (sharp, libvips, Pillow)? Patch.
• Any new file types customers ask for? Risk-evaluate before adding.
• Public bucket review: any paths that should be private got promoted?
• Last virus-scan signature update?

Compliance:

• Privacy policy current with what we collect from uploads (EXIF stripping etc.)?
• Deletion SLA met for the period?
• Any regulator inquiries?

Output:

• Health snapshot
• 3 fixes to ship next quarter
• 1 quota / pricing adjustment if appropriate
• 1 file type to consider adding or removing

---

## What "Done" Looks Like

A working file-upload system in 2026 has:

- **Direct-to-storage** uploads via presigned URLs (never proxy through app server)
- **Strict allowlist** of file types and sizes
- **Magic-byte verification** post-upload
- **Image processing** with EXIF stripping and variant generation
- **Virus scanning** for shared / regulated use cases
- **Signed URLs** for private file delivery
- **Per-tenant quotas** with clear UI
- **Soft-delete + grace period** for files
- **Garbage collection** for orphans
- **Audit logs** for high-value events
- **Customer-facing storage usage UI**
- **Quarterly review** baked into the team rhythm

The hidden cost in file uploads isn''t the storage bill — it''s **the security incident from one bad file format choice**. SVG with embedded JS was the 2018 wave; HEIC bombs hit 2020; new format-confusion attacks land every year. Stay conservative on the allowlist; subscribe to security mailing lists for image / parser libraries; patch when CVEs land. The discipline is what keeps the feature safe; the tool is the easy part.

---

## See Also

- [Multi-Tenant Data Isolation](multi-tenancy-chat.md) — uploads are workspace-scoped
- [Roles & Permissions (RBAC)](roles-permissions-chat.md) — who can upload? who can read?
- [Audit Logs](audit-logs-chat.md) — every upload event logged
- [Account Deletion & Data Export](account-deletion-data-export-chat.md) — files purged here
- [CSV Import Flows](csv-import-chat.md) — companion bulk-data flow
- [API Keys & PATs](api-keys-chat.md) — programmatic uploads use these
- [File Storage Providers](https://www.vibereference.com/cloud-and-hosting/file-storage-providers) — choose your backend
- [Background Jobs Providers](https://www.vibereference.com/backend-and-data/background-jobs-providers) — image / virus-scan workers run here
- [Vercel Blob](https://www.vibereference.com/cloud-and-hosting/vercel-blob) — Vercel-native storage
- [Cloudflare](https://www.vibereference.com/cloud-and-hosting/cloudflare) — R2 storage and CDN

[⬅️ Growth Overview](README.md)