File Upload Security Testing Services

Most vulnerability classes let an attacker read data or run script in someone’s browser. A broken file upload can let them run code on your server. That is the ceiling, and it is why we treat upload testing as a high-priority exercise rather than a quick check of the accept attribute. The distance from “the form accepts a .php file” to “the attacker controls the server” is often a single request, and closing that gap is the point of the engagement.

Good upload handling validates in layers, and an attacker only needs one layer to be weaker than it looks. Client-side checks are cosmetic and fall away the moment the request is crafted by hand. Extension allowlists are bypassed with alternate extensions the server still executes. Content-type headers are attacker-controlled and mean nothing on their own. Even content sniffing is beaten by a polyglot file that is a valid image and a valid script at once. We test each layer against the tricks that defeat it.

We identify every place a file can enter: profile photos, document uploads, import features, attachments, avatars, even indirect paths like a URL the server fetches and saves. For each we establish what the server checks, where the file lands, what name it keeps, and whether it can be reached again over HTTP.

We work through the checks one at a time.

Extension and content-type

We try alternate executable extensions, double extensions like invoice.pdf.php, trailing characters, and mismatched content-type headers, watching which combination the server accepts and, more importantly, later executes.

Magic bytes and polyglots

Where the server validates file contents, we craft files that carry a valid image header and a malicious payload in the same file, so a content check passes while the executable part survives.

Filename and path traversal

We test whether traversal sequences in the filename let a file be written outside the upload directory, into a web-served or system location, which turns an upload into arbitrary file write.

A file that is accepted is only interesting if it can do something. We confirm whether an uploaded script can be requested and executed, whether an SVG runs in a viewer’s browser, or whether an XML file’s external entities read server files. We prove the outcome with a benign, controlled payload and stop there, with every intrusive step agreed in the rules of engagement first.

The worst case. If a server-side script can be uploaded and reached by URL, the attacker runs code as the web application, reads configuration and secrets, and pivots deeper. We test the full path, from upload to execution, and where it works it is the headline finding in the report.

An SVG is XML, and XML can carry script. Uploaded as an avatar and served inline, a malicious SVG runs in the browser of everyone who views it. We test whether image uploads are sanitised or served with a content type that prevents execution.

Formats built on XML, including SVG, DOCX and some spreadsheets, can define external entities. A parser that resolves them can be steered into reading local files or making server-side requests, turning an innocent document upload into information disclosure or SSRF.

Missing size and count limits let an attacker exhaust disk or bandwidth. Decompression bombs, tiny archives that expand to gigabytes, do the same to memory. We check the limits that keep an upload feature from becoming an availability problem.

A plain-language read on whether your upload features can be turned into code execution, stored attacks on your users, or a denial-of-service, and what each would cost.

Each finding lists the upload point, the bypass used, the resulting impact, a CVSS score, reproduction with the exact request and file, and a specific fix, from server-side validation and content-type enforcement to storing files off the web root and serving them with a safe disposition.

After your team applies the fixes we re-test every finding at no charge and confirm the bypass no longer works, across each variation we found.

Unrestricted file upload maps to OWASP Top 10 categories for injection and security misconfiguration, and to specific OWASP ASVS file-handling requirements. We test against these so your developers get a recognised structure for both findings and fixes.

Any system that accepts files from users and handles payment or personal data falls under these frameworks’ testing and hardening expectations. The report and attestation letter are written to support PCI DSS, ISO 27001, SOC 2 and GDPR. Tell us your framework and we align the deliverables.

Uploaded files often become URLs, and those URLs are frequently guessable or sequential. We test whether one user can reach another user’s uploaded documents by altering the path, which on a KYC or invoicing feature is a straightforward personal-data breach on top of the execution risks.

Many apps push uploads to object storage or a processing service. That moves the risk without removing it. We check whether a pre-signed URL is over-permissive, whether a processing pipeline parses the file unsafely, and whether the bucket serving user content is configured to prevent inline execution.