File Upload Testing Checklist.

Upload a standard file within the allowed type and size. Confirm it appears in the UI file list, the database record is created with the correct metadata (name, size, type, upload timestamp), and the file is actually stored in the configured storage backend (check S3/GCS object or filesystem path).

Upload a file large enough to take >1 second. The UI must show a visible in-progress state. After completion, the progress state must clear and the file must appear in the file list without a page refresh.

Drag a valid file onto the drop zone. Confirm the file is processed identically to one selected via the <input type='file'> picker — same validation, same storage path, same metadata. Also verify that dragging a non-file (e.g., text selection) onto the drop zone is handled gracefully.

Assert the POST /upload (or presigned URL PUT) returns a 200/201 with the file ID, storage URL, content type, and size. Clients should not need to make a second request to discover where the file is stored. Inconsistent responses cause frontend state desync.

Upload file.pdf, then upload a different file also named file.pdf. The second upload must either: be stored with a deduplicated name (file_1.pdf), or prompt the user to confirm overwrite. Silent overwrites cause permanent data loss.

For each type listed in the documented allowlist, upload a real file of that type and verify it stores and displays correctly. Do not only test JPEG — if DOCX is listed, test it explicitly. Different MIME types have different handling in multipart parsers.

Remove the 'accept' attribute from the <input type='file'> via DevTools and upload a .exe, .php, .sh, or .js file. The server must return a 400 with a clear error ('File type not allowed'). Relying on the browser's accept attribute for security is ineffective.

Rename a PHP script to photo.jpg and upload it. Rename a JPEG to script.php and upload it. The server must inspect the actual file signature (magic bytes: FFD8FF for JPEG, %PDF for PDF) — not trust the client-provided Content-Type or the extension alone. Extension-only checks are trivially bypassed.

A polyglot file is both a valid JPEG and a valid PHP script. Upload one (tools like JPEGphp can generate them). If the file passes type validation and is served from a web-accessible path, the server could execute the PHP. Validate MIME type from content and ensure uploaded files are served with a Content-Disposition: attachment header.

Upload files named photo.jpg.exe and document.pdf.php. The server must classify these by the actual file signature — not the last extension or the first extension. Some file upload middleware only checks the final extension, classifying .jpg.exe as 'jpg'.

Generate a file at exactly the documented limit (e.g., 10 MB). Upload it. It must succeed. Off-by-one errors in size validation commonly cause 'file is too large' errors for files at exactly the limit.

Generate a file at limit + 1 byte. Upload it. Expect a 413 Payload Too Large or a 400 with a message like 'File exceeds the 10 MB limit'. The error must state the limit so users know what to do. A generic 'Upload failed' is not acceptable.

Upload a 0-byte file. Expect a 400 with 'File cannot be empty' — not a silent success that stores an empty record, and not a 500 from a divide-by-zero or null pointer in the file processing pipeline.

Bypass the frontend size check (modify the validation JS in DevTools or send the request directly via curl) and upload an oversized file. The server must still return 413 or 400. Frontend-only size checks can be bypassed in 30 seconds.

Upload a file named '../../etc/passwd', '../config/database.yml', and '..%2F..%2Fetc%2Fshadow'. The server must sanitize these to a safe name (e.g., strip all directory components) before writing to storage. Path traversal in filenames can overwrite server files or expose sensitive paths.

Upload files named: 'my file (draft).pdf', 'résumé.docx', 'report&analysis.xlsx', 'test<script>.png'. The server must either store the exact name safely (with correct encoding) or strip/replace special characters. The filename returned via the API must match what is actually stored.

Upload a file with a name of 300+ characters. The server must either truncate to a safe length or reject with 400 — not crash with a filesystem error or an unhandled exception. Most filesystems have a 255-byte filename limit.

Inspect the actual storage path (S3 key, filesystem path, or database record). The stored file should use a server-generated identifier (UUID, hash of content) — not the raw user-provided filename. Storing the raw filename exposes path traversal risk and naming conflicts.

Select 5 valid files of different types and sizes. All must upload and appear in the file list. Check the database: exactly 5 records should be created. Check storage: exactly 5 objects should exist.

If the limit is 10 files, select 11. The UI should indicate which files were rejected and why ('Maximum 10 files allowed'). The server should also enforce this limit independently — a direct API call with 11 files should return 400.

Include one valid file and one invalid file (wrong type or oversized) in a multi-select upload. The valid file must upload successfully. The invalid file must show an error alongside the success for the valid one — the entire batch should not be rejected because of one bad file.

If the per-file limit is 10 MB and the batch limit is 50 MB, upload 6 files of 9 MB each (54 MB total). The server must reject the batch for exceeding the total limit — not accept all 6 because each is individually under 10 MB.

After uploading a JPEG and PNG, navigate to any page that shows an image preview. Confirm the images render. If files are served from a CDN or separate origin, check that CORS headers allow the preview to load. Open the Network tab and verify no blocked requests.

Click the download link for a PDF, HTML, and SVG file. Verify in the Network tab that the response includes 'Content-Disposition: attachment; filename="..."'. Without this header, browsers may render HTML or execute SVG inline, enabling stored XSS via uploaded files.

Note the direct storage URL of a file. Delete the file. Attempt to access the URL directly (in a new incognito window to avoid cache). The server must return 404 or 403. Soft-delete patterns that only mark a DB record as deleted but leave the storage object accessible are a data-leak risk.

As User A, upload a file and note its ID. Authenticate as User B. Call DELETE /files/{fileId} with User A's file ID. Expect 403 or 404. If the file is deleted, an IDOR (Insecure Direct Object Reference) vulnerability exists in the delete endpoint.

Copy the download URL for a private file. Log out (or open in an incognito window without the session cookie). Attempt to access the URL. Expect 401/403 for signed/authenticated URLs, or a 403/404 for expired presigned URLs. Files stored on public cloud paths without auth checks are world-readable.

Upload the EICAR test string (a harmless standard antivirus test file) if your infrastructure uses an AV scanner. The upload should either be rejected immediately or quarantined before becoming accessible to downloaders. Files stored directly and served without scanning risk malware distribution via your platform.

If ZIP or TAR files are accepted and extracted server-side, upload a zip bomb (a highly compressed file that expands to gigabytes). The server must limit the extraction size and terminate decompression after the limit. A zip bomb can exhaust disk space and cause a denial of service.

Upload files named shell.php, exploit.asp, payload.jsp, and test.cgi to a directory that is web-accessible. Attempt to access the URL directly and verify the file is downloaded (not executed) or returns 403. Never store uploaded files in a web-accessible directory — use a non-public storage path or bucket.

Upload a JPEG with embedded GPS coordinates, camera model, and author name (tools like ExifTool can add these). Download the file and inspect its EXIF data. Location data in user-uploaded photos is a privacy violation — strip all EXIF metadata server-side before storing or serving.

Upload an SVG containing <script>alert(document.cookie)</script>. If the SVG is served inline (image src or embed), the script must not execute. Either block SVG uploads, sanitize SVG content server-side (remove script/foreignObject tags), or serve all SVGs with Content-Disposition: attachment.

Tab to the upload button or drop zone. Press Enter or Space to open the file picker. The picker must open on keyboard activation. Custom drop zones that only respond to mouse events exclude keyboard-only users.

Attempt to upload an invalid file type or an oversized file. The error message must be associated with the upload control via aria-describedby, or injected into an aria-live='polite' region. Screen reader users must hear the error without being directed to look at a visual toast that disappears.

Simulate a network failure mid-upload (DevTools → Network → Offline, or use cy.intercept to return a 500). The UI must show: an error message explaining the failure, and a button to retry the upload. The file should not disappear from the upload queue.

Test all error conditions: wrong MIME type, oversized file, zero-byte file, too many files. Each must produce a specific message that tells the user what went wrong and how to fix it. 'Upload failed' without context is not actionable.