Uploaded files are untrusted content that can execute, overwrite other files, exhaust storage or deliver malware to other users.
- Document permitted file types, extensions and maximum sizes, including the unpacked size of archives.
- Check file content against the allowed types, and enforce per-user quotas.
- Store files under server-generated names, outside paths that execute code.
- Serve downloads with headers that stop browsers from rendering them as active content.
Each requirement has a level. Level 1 holds the first-layer defenses (about a fifth of the standard), Level 2 adds what OWASP says most applications should strive for, and Level 3 adds defense-in-depth and harder-to-implement controls; meeting a level means meeting every requirement of the levels below it too. Cite a requirement with the version, for example v5.0.0-5.1.1.
V5.1 File Handling Documentation · 1 requirement
V5.1.1 Level 2
Verify that the documentation defines the permitted file types, expected file extensions, and maximum size (including unpacked size) for each upload feature. Additionally, ensure that the documentation specifies how files are made safe for end-users to download and process, such as how the application behaves when a malicious file is detected.
V5.2 File Upload and Content · 6 requirements
V5.2.1 Level 1
Verify that the application will only accept files of a size which it can process without causing a loss of performance or a denial of service attack.
On this site: Design a safer file-upload pipeline (guide) · Unrestricted file upload (fix card)
V5.2.2 Level 1
Verify that when the application accepts a file, either on its own or within an archive such as a zip file, it checks if the file extension matches an expected file extension and validates that the contents correspond to the type represented by the extension. This includes, but is not limited to, checking the initial 'magic bytes', performing image re-writing, and using specialized libraries for file content validation. For L1, this can focus just on files which are used to make specific business or security decisions. For L2 and up, this must apply to all files being accepted.
On this site: Design a safer file-upload pipeline (guide) · Convert untrusted office documents and PDFs in an isolated parser (guide) · Unrestricted file upload (fix card)
V5.2.3 Level 2
Verify that the application checks compressed files (e.g., zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file.
On this site: Extract archives without escaping the destination (guide) · Convert untrusted office documents and PDFs in an isolated parser (guide)
V5.2.4 Level 3
Verify that a file size quota and maximum number of files per user are enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files.
V5.2.5 Level 3
Verify that the application does not allow uploading compressed files containing symlinks unless this is specifically required (in which case it will be necessary to enforce an allowlist of the files that can be symlinked to).
On this site: Extract archives without escaping the destination (guide)
V5.2.6 Level 3
Verify that the application rejects uploaded images with a pixel size larger than the maximum allowed, to prevent pixel flood attacks.
On this site: Design a safer file-upload pipeline (guide)
V5.3 File Storage · 3 requirements
V5.3.1 Level 1
Verify that files uploaded or generated by untrusted input and stored in a public folder, are not executed as server-side program code when accessed directly with an HTTP request.
On this site: Prevent file inclusion: LFI, RFI, dynamic imports and template names (guide) · Unrestricted file upload (fix card)
V5.3.2 Level 1
Verify that when the application creates file paths for file operations, instead of user-submitted filenames, it uses internally generated or trusted data, or if user-submitted filenames or file metadata must be used, strict validation and sanitization must be applied. This is to protect against path traversal, local or remote file inclusion (LFI, RFI), and server-side request forgery (SSRF) attacks.
On this site: Design a safer file-upload pipeline (guide) · Prevent file inclusion: LFI, RFI, dynamic imports and template names (guide) · Create temporary files safely: mkstemp, O_EXCL and private directories (guide) · Unrestricted file upload (fix card)
V5.3.3 Level 3
Verify that server-side file processing, such as file decompression, ignores user-provided path information to prevent vulnerabilities such as zip slip.
On this site: Extract archives without escaping the destination (guide)
V5.4 File Download · 3 requirements
V5.4.1 Level 2
Verify that the application validates or ignores user-submitted filenames, including in a JSON, JSONP, or URL parameter and specifies a filename in the Content-Disposition header field in the response.
On this site: Design a safer file-upload pipeline (guide) · Consume third-party APIs safely (OWASP API10:2023) (guide) · Unrestricted file upload (fix card)
V5.4.2 Level 2
Verify that file names served (e.g., in HTTP response header fields or email attachments) are encoded or sanitized (e.g., following RFC 6266) to preserve document structure and prevent injection attacks.
V5.4.3 Level 2
Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent serving of known malicious content.
Requirement IDs, levels and text are from the OWASP Application Security Verification Standard 5.0.0 (copyright © 2008-2025 The OWASP Foundation), unmodified, under the Creative Commons Attribution-ShareAlike 4.0 International License. Imported from release v5.0.0_release (commit 5cf9b03); license.
Guides on this site
Design a safer file-upload pipeline
Treat upload receipt, content processing, storage, and later delivery as separate security decisions.
Extract archives without escaping the destination
Prevent traversal, link tricks, overwrites and decompression exhaustion while preserving legitimate file extraction.
Practice
- Path traversal lab: Keep archive entries inside their extraction directory · Browser lab
- Path traversal lab: Serve an uploaded file without path traversal · Browser lab
- File upload lab: Accept avatars without publishing pages · Browser lab
- Keep extracted files inside their boundary · Local project
- Convert untrusted documents in a locked-down container · Local project
References
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.