AI Coding Agents
Security
File upload security tests with coding agents
September 28, 2026 - 2 minute read
File upload security testing verifies every stage between receiving bytes and serving them again. Coding agent changes may add a new MIME type, alter object-store permissions, move validation after persistence, or expose predictable retrieval paths. A successful upload response does not prove that the workflow is safe.
The OWASP File Upload Cheat Sheet recommends defense in depth. It covers extension allowlists, content-type validation, generated filenames, size limits, storage outside the web root, authorization, and malware or content analysis where appropriate.
Map file upload security testing
Map the request limit, multipart parser, temporary storage, validation, transformation, permanent storage, metadata database, and download handler. Record where each rejection happens and which cleanup action follows. Tests should assert that rejected content leaves no orphaned object or database row.
Use small synthetic fixtures for permitted and prohibited cases. Include mismatches between extension, declared MIME type, and file signature. Cover empty files, duplicate names, unusually long names, nested archive names, Unicode normalization, and size boundaries just below and above the configured limit.
Do not place live malware in the repository. Security scanners commonly publish harmless test signatures for integration checks. Use only the approved fixture for the deployed scanner.
Set processing timeouts as well as byte limits. A compact archive or malformed document can consume disproportionate CPU, memory, or extracted storage even when the original upload stays below its size ceiling.
Test storage and retrieval controls
An accepted file should receive a server-generated storage key. Test that the original name cannot select a path, overwrite another tenant’s object, or escape a temporary directory. Verify permissions on temporary and permanent storage.
Retrieval needs independent authorization. Create two users or tenants, upload as one, and attempt access as the other. Test direct object URLs, thumbnail or conversion endpoints, and cached responses. Deleting a database row should not leave a public object reachable under its old URL.
When content is served inline, verify the response content type and disposition. Active formats need a documented policy because browsers may interpret uploaded HTML, SVG, or office documents in ways the application did not expect.
Give a coding agent bounded upload tests
Provide the allowed types, size limits, scanner behavior, storage policy, and retention rules. Name the existing upload entry points and test helpers. Require assertions for cleanup and authorization rather than only response codes.
Factory’s Security Review can examine pull requests against OWASP and supply-chain concerns. Repository-specific guidance can direct reviewers to multipart parsing, object-store policy, content transformation, and download authorization. The executable fixture suite remains the source of evidence for the application’s exact policy.
Review file upload security evidence
Run fixtures against an isolated bucket or local storage emulator. Use unique prefixes and delete test objects after assertions. Record object keys and outcomes without retaining uploaded contents in ordinary CI logs.
Review the negative cases first. Every prohibited fixture should fail closed with a stable client error and no retrievable artifact. Then confirm that valid uploads still complete, preserve required metadata, and remain available only to authorized readers.
