Secure File Uploads in WordPress Forms

Custom upload fields give contact forms and WooCommerce checkout flows a practical way to collect documents, but they also create an easy path for oversized files, forged requests, executable payloads and accidental disclosure. WordPress can validate and move a file; it does not automatically make that file private or safe to execute. A secure design therefore treats upload handling as a complete trust boundary, not merely a form field.

Australian businesses commonly use WordPress for quote requests, support, proof of delivery and membership forms. Their users may submit large phone photos, HEIC images, invoices or scanned IDs over a mobile connection. Those files can contain addresses, signatures and other personal information, while cloud choices often favour regions around Sydney or Melbourne. Keeping WordPress, PHP and server packages current is essential, but configuration and data handling remain equally important.

A dependable flow validates the request, inspects content, stores it outside executable paths, scans it and removes it when retention expires. It also records enough information to investigate abuse without filling logs with personal data. These controls work together: a MIME check cannot replace authorisation, and malware scanning cannot repair unsafe storage.

Start with a threat model

Start by deciding who may upload, what they can upload and where files go. Consider anonymous visitors, subscribers, customers, editors and administrators as separate actors. The threats include malicious users bypassing validation, stolen sessions, IDOR requests exposing another customer’s attachment, parser exploitation and execution through an uploads directory. A written threat model makes trade-offs visible before custom PHP duplicates capabilities WordPress already provides.

Define the policy in measurable terms: permitted formats, maximum bytes, image dimensions, permitted roles, retention period, public or private access and whether original metadata must survive. PDFs need a separate decision because they can contain JavaScript, embedded files and exploit payloads. If users do not need macros or embedded content, accepting only flattened JPEG or PNG files reduces risk before processing begins.

The processing path should move from PHP’s temporary area to quarantine, validation, scanning, optional re-encoding and approved storage. Reject malformed multipart data with a generic message, clean temporary files and record status codes without full paths. Avoid logging original names, signed URLs or uploaded content. Tests should cover oversized requests, mismatched MIME types, double extensions and attempts to reach files belonging to other records.

Validate every upload server-side

Treat anything sent by the browser as hostile. The accept attribute and client-side JavaScript improve usability but provide no security guarantee. Use multipart/form-data, enforce limits below both post_max_size and upload_max_filesize, and check the upload error before processing. Browser headers, original filenames and supplied MIME types are attacker-controlled; server-side inspection and an allowlist must decide acceptance.

For a low-risk, non-confidential image field, a minimal WordPress-native stage can begin after authentication and CSRF checks:

$file = $_FILES['proof'] ?? null;

if ( ! is_array( $file ) ||
	UPLOAD_ERR_OK !== (int) ( $file['error'] ?? UPLOAD_ERR_NO_FILE )
) {
	wp_die( 'The upload failed.', 'Upload error', array( 'response' => 400 ) );
}

$limit = min( 10 * 1024 * 1024, wp_max_upload_size() );

if ( (int) $file['size'] > $limit ) {
	wp_die( 'The file is too large.', 'Upload rejected', array( 'response' => 413 ) );
}

$mimes = array(
	'jpg'  => 'image/jpeg',
	'jpeg' => 'image/jpeg',
	'png'  => 'image/png',
);

$attachment_id = wp_handle_upload(
	$file,
	array(
		'test_form' => false,
		'mimes'     => $mimes,
	),
	$upload_error
);

if ( is_wp_error( $attachment_id ) ) {
	wp_die( 'The file type was rejected.', 'Upload rejected', array( 'response' => 415 ) );
}

wp_handle_upload calls wp_check_filetype_and_ext and core upload checks, but custom workflows should also compare the MIME type detected by finfo with the allowed policy and reject mismatches. Use wp_unique_filename and sanitize_file_name for naming and display; neither authorises an extension or prevents every parser attack. Reject executable, archive and legacy double-extension formats by default.

For a private workflow, leave the HTTP upload in a private temporary directory, run all checks there and move it only after scanning. wp_handle_sideload can process a trusted server-side path, but it must never receive a path supplied by the client. Verify actual image dimensions and pixel count before decoding, cap memory usage and update ImageMagick or GD. Upload validation inherits their parser vulnerabilities.

Authenticate and authorise the request

A nonce proves that a request came from a page issued to the current WordPress user; it does not prove that the person may upload a file for a particular order. After authentication, verify a nonce and check a real capability. Create a dedicated capability for the workflow rather than granting broad administrator permissions to every form user.

if (
	! isset( $_POST['upload_nonce'] ) ||
	! wp_verify_nonce(
		sanitize_text_field( wp_unslash( $_POST['upload_nonce'] ) ),
		'submit_customer_document'
	) ||
	! current_user_can( 'submit_customer_document' )
) {
	wp_die( 'Not authorised.', 'Upload rejected', array( 'response' => 403 ) );
}

For front-end forms, define custom capabilities such as submit_customer_document and assign them intentionally to the relevant roles. On every later request, check ownership or the relationship between the current user and the target record; possession of an attachment ID must never grant access. Administrators may need separate override logic with an audit event.

Anonymous forms need additional controls because WordPress treats nonces for logged-out visitors as anonymous and they cannot express per-user ownership. Use a server-side, single-use token with a short expiry, rate limits by IP and account, a honeypot and, where risk warrants it, a CAPTCHA. For AJAX, combine check_ajax_referer with authentication, capability and record-level checks. Reject replayed submissions, enforce quotas and keep event logs free of document contents and sensitive personal data.

Store files outside executable paths

Do not assume the WordPress media library is a private vault. Standard attachments receive direct URLs and may sit beside executable file types if the web server is configured incorrectly. Put confidential material outside the public document root where possible. A PHP controller can read it only after repeating authentication and authorisation, then send it with safe response headers. Random names reduce guessing but do not replace access control.

At minimum, disable handlers and CGI execution in every upload directory, including temporary and newly created paths. Deny dotfiles, set ownership to the web service account and writable permissions only where required, and reject symbolic-link tricks. On Apache and Nginx, test the effective configuration because rewrite and handler ordering can bypass an intuitive rule. Use the applicable block and adjust the path:

<Directory /srv/www/wp-content/uploads>
    Options -ExecCGI
    <FilesMatch "\.(?i:php[0-9]?|phtml|phar|cgi|pl|py|sh)$">
        Require all denied
    </FilesMatch>
</Directory>

location ^~ /wp-content/uploads/ {
    location ~* \.(php|phtml|phar|cgi|pl|py|sh)$ {
        return 403;
    }
    add_header X-Content-Type-Options nosniff always;
}

Generate storage names with cryptographic randomness, such as a 32-character hexadecimal token plus a policy-approved suffix, and keep the user’s sanitised display name in a separate database field. Never concatenate $_FILES paths. Associate metadata with a custom post type or dedicated upload record and verify its owner whenever it is viewed, replaced or deleted.

Private buckets in Australian Sydney or Melbourne regions can replace local disks. Use server-side encryption, short-lived signed URLs and explicit lifecycle rules rather than public objects. Ensure CDN caches do not retain material after a user loses access.

Process and scan content safely

Place untrusted content in quarantine and scan it before promotion. WordPress does not include a general-purpose malware scanner, so use a maintained ClamAV service, host-level scanner or specialist scanning API. Keep its signatures current and design for timeouts and unavailable scanners: fail closed for sensitive documents. A clean result supports the control set but never replaces execution restrictions, content inspection and least-privilege storage.

Images deserve re-encoding rather than simple renaming. Decode with a patched, resource-limited process, check dimensions before allocation and save a fresh JPEG or PNG without profiles, thumbnails or EXIF GPS data. HEIC conversion is useful for iPhone uploads, but isolate the converter and impose time, CPU and memory limits. ImageTragick-style bugs, malformed images and decompression bombs show why framework updates and parser sandboxing remain necessary.

Office files, PDFs and archives carry active content that a signature-based scanner may miss. Reject archives unless essential, never extract them in the document root, and do not permit macros or embedded executables. If PDFs are necessary, remove active content with a maintained sanitiser, serve them from an isolated origin under a separate cookie scope, and force downloads where inline viewing is unnecessary.

Apply Content-Disposition: attachment, X-Content-Type-Options: nosniff and a sandbox policy to file responses. Use Cache-Control: private, no-store for authenticated material, and never place uploads in a shared, publicly writable directory.

Protect personal data across its lifecycle

Where the Privacy Act 1988 applies, the Australian Privacy Principles govern the workflow. Collection needs a clear purpose, use and disclosure need authority, security safeguards must be reasonable, and people need practical access and correction routes. A small business should not upload passports, tax documents or customer media to a public WordPress gallery without assessing sensitivity, necessity and retention. Give a concise privacy notice at collection and obtain consent where required for sensitive information.

Set deletion rules when the workflow starts and apply them to files, attachment metadata, custom records and derived thumbnails. Expiry jobs should be idempotent and tested against retries and partial failures; backups and object versioning can otherwise resurrect deleted copies. Redact logs, encrypt data in transit and at rest, protect signing keys and prepare an incident process aligned with the Notifiable Data Breaches scheme. Australian Cyber Security Centre guidance is a useful reference, and marketing email triggered by a form must also be assessed under the Spam Act 2003.

Storage approach	Public exposure	Important controls	Suitable use	Main trade-off
WordPress media library	Direct URLs are public by default	MIME allowlist, execution denied, safe filenames	Public, non-sensitive images	Simple, but unsuitable for confidential documents
Private local directory	No direct public URL	Outside web root, authenticated controller, server scanning	Sensitive uploads on one server	Backups, permissions and capacity require manual management
Private object storage	No public objects	Encryption, private bucket, signed URLs, lifecycle rules	Distributed applications and predictable growth	Additional provider cost and integration complexity
Isolated document service	Separate serving origin	Malware scanning, active-content removal, sandboxed conversion	PDFs and office documents with complex content	Vendor dependence and greater operational complexity

Choose the narrowest storage model that fits the data. The WordPress media library remains reasonable for public, non-sensitive images; a directory outside the web root fits a controlled single-server installation; private object storage supports multiple application servers and predictable capacity. Australian regions around Sydney and Melbourne can support low-latency processing, but region choice does not replace access controls. Test direct URLs, spoofed MIME types, script execution, cross-user access and deletion before deployment, then repeat those checks whenever PHP, WordPress or server configuration changes.