Set upload budgets across requests and processing
Define per-file, request, storage, and processing limits. Test streamed uploads, concurrent reservations, partial cleanup, and legitimate near-limit files.
A single maximum file size does not describe an upload budget. A request can contain many files, several requests can arrive together, and a small input can require substantial processing or expanded storage. Define limits around the resources the feature actually consumes.
OWASP includes upload and download limits in its file-upload guidance. The budget sheet below is an application-specific planning aid. Select values from the intended workflow and measured capacity rather than copying arbitrary numbers.
Assign a limit to each resource
Identify where a limit is enforced and what happens when it is exceeded. A client-side warning helps users, but the server or storage service must enforce the boundary independently.
| Resource | Enforcement point | Failure requirement |
|---|---|---|
| Bytes per file | Stream reader or storage policy | Stop accepting bytes and remove partial data |
| Files per request | Multipart parser | Reject extra parts without processing them |
| Aggregate request size | Edge and application | Consistent bounded response |
| Tenant storage | Atomic reservation and completion | Concurrent uploads cannot overspend quota |
| Processing time and memory | Worker supervisor | Terminate work and record disposition |
Include abandoned multipart uploads and temporary conversion outputs in the capacity model. They consume space even when the user never receives a completed file.
Exercise boundaries with small controlled fixtures
Configure reduced test limits so the regression can cross a boundary without consuming production-scale resources. Test below, at, and above each limit. Include a streamed request without a trustworthy declared length, where your stack supports it.
Run a bounded concurrency test against a synthetic tenant. Confirm that simultaneous reservations cannot each observe the same available quota and all succeed. Inspect actual stored bytes and temporary objects after rejection, not only the response status.
Make recovery visible
Record how reservations expire, how interrupted uploads are removed, and which job reconciles discrepancies. Give cleanup an owner and an observable result. A quota counter that decreases while orphaned objects remain is not a complete cleanup.
Keep legitimate near-limit uploads in the positive test set. Check that cancellation releases capacity and that a failed conversion does not permanently consume a user's allowance. Retain the tested limits, build, resource observations, and cleanup result. This makes a future quota increase a reviewable capacity decision instead of a silent change to the application's denial-of-service exposure.
Find the gaps before your next launch
Use the release checklist to identify changed security boundaries and missing evidence. Discuss the application paths you want reviewed before launch.
Sources
- OWASP File Upload Cheat SheetAccessed