Large File Accepted Despite Size Limit
The application documents a 10 MB file upload limit, but a 25 MB file is accepted by the backend and stored successfully. The size check is enforced only by the frontend, so a request sent directly to POST /api/documents/upload bypasses the limit entirely.
MediumBeginnerManual testingAPI testingNegative testing
// UNDERSTAND
// Symptoms
- A 25 MB file sent directly to POST /api/documents/upload returns 200 OK
- The frontend correctly shows 'File exceeds 10 MB limit' when a large file is selected via the file picker, but the same file is accepted when uploaded via the API
- Large files consume unexpected storage and bandwidth — monitoring shows uploads well above the documented limit
- No size-limit error appears in server logs or the API response for oversized uploads
// Root Cause
- The file size check is implemented only in a JavaScript event handler on the frontend file-picker component. The backend API handler has no server-side size limit configured — or the server's multipart-body parser is configured with a much higher limit (e.g. 100 MB) than the documented 10 MB
- The backend web framework's default body size limit (often 50 MB or unlimited for multipart forms) is used without overriding it to match the documented application limit of 10 MB
// Where It Appears
- Document and image upload endpoints in content management systems
- Profile photo upload endpoints where storage costs are sensitive to file size
- Support attachment endpoints where very large files can degrade application performance
- Any endpoint where the frontend and backend size limits are configured independently
// REPRODUCE & TEST
// How to Reproduce
- 01Authenticate as a standard user and obtain the bearer token
- 02Prepare a test file that is 25 MB (e.g. generate with: dd if=/dev/urandom of=testfile_25mb.bin bs=1M count=25)
- 03Send a multipart/form-data POST request to /api/documents/upload with testfile_25mb.bin attached and the bearer token in the Authorization header
- 04Observe the HTTP response status code and body
- 05If the response is 200 OK with a file URL, the 25 MB file was accepted despite the 10 MB limit
// Test Data Needed
- A valid user account with permission to upload documents
- A test file slightly above the limit (e.g. 10.1 MB) and one well above it (e.g. 25 MB) to test both the boundary and a clear violation
- A way to send raw multipart/form-data requests (Postman, curl, or Python requests)
// Manual Testing Ideas
- Use the file picker in the UI to select a 25 MB file and confirm the frontend shows a size-limit error
- Send the same 25 MB file directly to POST /api/documents/upload via Postman and confirm the API still rejects it with 413 Request Entity Too Large or 422
- Test the boundary: send a file at exactly 10 MB and confirm it is accepted; send a file at 10.1 MB and confirm it is rejected
- Try uploading a 25 MB file in chunks if the API supports chunked uploads — confirm the assembled size is also validated
- Check the server configuration or application code to find the actual maxFileSize value in the multipart parser
// API Testing Ideas
- Authenticate and obtain a bearer token
- Send POST /api/documents/upload with a 9.9 MB file; assert the response is 200 OK — this confirms the limit allows files under 10 MB
- Send POST /api/documents/upload with a 10.1 MB file; assert the response is 413 Request Entity Too Large or 422 Unprocessable Entity
- Send POST /api/documents/upload with a 25 MB file; assert the response is 413 or 422 — if it returns 200, the bug is confirmed
- Confirm the response body for the rejected oversized file contains a message indicating the size limit
// Automation Idea
Generate test files at three sizes programmatically: 9.9 MB (should be accepted), 10.1 MB (should be rejected), and 25 MB (should be rejected). For each size, send POST /api/documents/upload and assert the expected HTTP status (200 for 9.9 MB, 413 or 422 for 10.1 MB and 25 MB). The test should generate files in code — do not commit large binary test fixtures to the repository.
// Expected Result
POST /api/documents/upload rejects any file larger than 10 MB with HTTP 413 Request Entity Too Large or 422 Unprocessable Entity, regardless of whether the request was sent via the UI or directly to the API.
// Actual Result (Example)
POST /api/documents/upload with a 25 MB file returns 200 OK with body { "url": "https://storage.example.com/docs/testfile_25mb.bin" }. The file is stored and the URL is accessible.
// REPORT IT
Example Bug Report
- Title
- POST /api/documents/upload accepts a 25 MB file despite the documented 10 MB limit
- Severity
- Medium
- Environment
- Staging environment Postman Valid bearer token Standard user account Test file: testfile_25mb.bin (25 MB)
- Steps to Reproduce
- 01Authenticate as a standard user and copy the bearer token
- 02Send POST /api/documents/upload as multipart/form-data with testfile_25mb.bin (25 MB) attached and the bearer token in the Authorization header
- 03Observe the HTTP response status code and body
- Expected Result
- The API returns 413 Request Entity Too Large or 422 Unprocessable Entity with a message indicating the file exceeds the 10 MB limit.
- Actual Result
- The API returns 200 OK with a file URL. The 25 MB file is stored successfully, bypassing the documented 10 MB limit.
- Impact
- Oversized files consume disproportionate storage and processing resources. Without a server-side limit, a malicious or accidental upload of very large files can exhaust storage, slow file-processing jobs, and increase infrastructure costs.