WordPress File Upload Security: A Validation Deep Dive

File upload vulnerabilities remain one of the most dangerous attack vectors in WordPress plugins. A single misconfigured upload handler can allow attackers to execute arbitrary code, compromise your entire site, and expose sensitive user data. Yet many developers continue to implement file uploads with minimal validation, leaving their plugins and the sites that use them vulnerable.

WordPress file upload security validation isn't just a nice-to-have feature—it's a critical requirement for any plugin handling user-submitted files. Whether you're building a media library extension, a document management system, or a simple form handler, understanding how to properly validate and secure file uploads is essential.

In this guide, I'll walk you through the complete anatomy of WordPress file upload security validation, from MIME type checking and extension validation to file size limits and the proper use of WordPress's built-in functions. I'll show you the vulnerable patterns that attackers exploit, and more importantly, how to implement rock-solid defenses that actually prevent these attacks.

The Critical Importance of File Upload Validation
MIME Type Validation and Its Limitations
Extension-Based Validation and Double Extension Attacks
Implementing File Size Limits Correctly
Using wp_handle_upload() Securely
Real-World Vulnerable Patterns and Fixes
Building a Comprehensive Upload Handler
Frequently Asked Questions

Why File Upload Security Matters

When a user uploads a file to a WordPress site, they're essentially asking your server to accept and store content. Without proper validation, an attacker can exploit this trust to upload a PHP file disguised as an image, execute code on your server, and take control of the entire WordPress installation.

The most common file upload vulnerabilities fall into a few categories:

Remote Code Execution (RCE): Uploading PHP, executable scripts, or other dangerous file types that the server will execute.

Path Traversal: Using specially crafted filenames like ../../../wp-config.php to write files outside the intended directory.

MIME Type Spoofing: Uploading a malicious PHP file with an image MIME type declaration.

Double Extension Attacks: Uploading files like shell.php.jpg that some servers interpret as executable.

Denial of Service: Uploading extremely large files to consume disk space and memory.

These vulnerabilities are preventable, but they require a defense-in-depth approach. You can't rely on a single validation method—instead, you need to layer multiple checks on top of each other. That's where a comprehensive WordPress file upload security validation strategy comes in.

The severity of file upload vulnerabilities cannot be overstated. A single misconfigured upload handler has compromised thousands of WordPress installations. Attackers actively scan for plugins with vulnerable upload handlers, making this one of the most targeted attack vectors in the WordPress ecosystem. The stakes are incredibly high because successful exploitation grants complete server access, allowing attackers to steal databases, inject backdoors, install ransomware, or use your server for malicious purposes. File upload security directly impacts the security posture of your entire WordPress installation.

Understanding your specific upload use case determines which validations are most important. A document management plugin handling PDFs and Word documents faces different threats than an image gallery plugin. A plugin allowing user avatars needs different security than a plugin managing CSV data imports. Your validation strategy should be proportional to the risk posed by the file types and the sensitivity of the data involved. Defense-in-depth ensures that even if one validation layer fails, others catch the attack.

MIME Type Validation

MIME types are the first line of defense in file upload validation. A MIME type (Multipurpose Internet Mail Extension) describes the content of a file, and browsers send this information when uploading files. However, MIME type validation alone is dangerously insufficient.

Here's why: MIME types are easily spoofed. An attacker can simply modify the file's MIME type metadata without changing the actual file content. A PHP shell script can be uploaded with an image MIME type, and many servers will blindly accept it based on the declared MIME type alone.

MIME types originate from the browser and are controlled entirely by the client. The browser examines the filename extension and makes a guess about the MIME type, then sends this guess with the upload request. An attacker with basic technical knowledge can intercept the request and modify the MIME type before it reaches your server. Even without intercepting the request, many HTTP clients allow specifying arbitrary MIME types. Validation relying solely on MIME types provides only the illusion of security, blocking naive uploads while permitting sophisticated attacks.

The vulnerability becomes more apparent when considering how browsers determine MIME types. The browser is just guessing based on file extension. You could upload a PHP file renamed to shell.jpg.jpg and the browser might still identify it as an image. Furthermore, the browser's MIME type detection varies across different browsers and systems, making any security assumption dependent on browser behavior fundamentally unreliable.

Let me show you the vulnerable pattern first:

// VULNERABLE: Relying only on MIME type
function upload_file_vulnerable( $file ) {
    if ( 'image/jpeg' === $file['type'] ) {
        move_uploaded_file( $file['tmp_name'], '/uploads/' . $file['name'] );
        return true;
    }
    return false;
}

This code checks the MIME type, but an attacker can easily change the $_FILES['type'] value in their request. This is not a reliable security check.

A better approach uses WordPress's wp_check_filetype() function, which checks both the MIME type and the file extension:

// BETTER: Using wp_check_filetype for initial validation
function upload_file_improved( $file ) {
    $allowed_types = array(
        'jpg|jpeg|jpe' => 'image/jpeg',
        'gif' => 'image/gif',
        'png' => 'image/png',
    );

    $file_type = wp_check_filetype( $file['name'], $allowed_types );

    if ( empty( $file_type['type'] ) ) {
        return new WP_Error( 'invalid_file_type', 'Invalid file type' );
    }

    move_uploaded_file( $file['tmp_name'], '/uploads/' . $file['name'] );
    return true;
}

However, even this approach has limitations. To truly validate file content, you should use PHP's finfo_file() function to examine the actual file contents and detect the real MIME type:

// SECURE: Validating actual file content with finfo
function upload_file_secure( $file ) {
    $allowed_types = array( 'image/jpeg', 'image/gif', 'image/png' );

    // Check actual file content, not just extension
    $finfo = finfo_open( FILEINFO_MIME_TYPE );
    $real_mime = finfo_file( $finfo, $file['tmp_name'] );
    finfo_close( $finfo );

    if ( ! in_array( $real_mime, $allowed_types, true ) ) {
        return new WP_Error( 'invalid_file_type', 'Invalid file type' );
    }

    // Additional checks...
    return true;
}

This approach examines the actual file content using magic bytes (file signatures), making it much harder for attackers to spoof file types. A JPEG file will always start with bytes FF D8 FF, and finfo_file() will detect this regardless of the filename extension.

Magic bytes, also called file signatures, are predictable patterns that appear at the beginning of files in specific formats. JPEG files always start with FF D8 FF, PNG files with 89 50 4E 47, and PDF files with 25 50 44 46. Because these byte sequences are inherent to the file format itself, attackers cannot fake them without actually creating a file in that format. The finfo_file() function examines these magic bytes and identifies the actual file type with high accuracy.

Implementing magic byte validation provides strong assurance that files are what they claim to be. However, the finfo functions require the fileinfo extension be installed and enabled, which is standard on most modern PHP installations but worth verifying. If your hosting doesn't provide fileinfo, you can implement a simpler magic byte check by reading the first few bytes and comparing them to known signatures, though this is less robust than using the library.

One limitation of magic byte validation is that it identifies file format but not malicious content within that format. A JPEG file is still a valid JPEG even if it contains embedded PHP code or other payloads, though such payloads won't execute through normal image processing. Magic byte validation ensures the file format is what you expect but doesn't verify the file is safe to serve or process.

Extension-Based Validation and Double Extension Attacks

File extensions are the second validation layer, but they're often mishandled by developers. A common mistake is trusting the file extension alone, or checking only the final extension in a filename.

Double extension attacks exploit this weakness. An attacker uploads a file named shell.php.jpg. Some configurations might process the file as PHP (if the server is misconfigured) while appearing to be an image due to the .jpg extension.

Here's a vulnerable pattern:

// VULNERABLE: Simple extension check
function validate_extension_bad( $filename ) {
    $ext = pathinfo( $filename, PATHINFO_EXTENSION );
    return in_array( $ext, array( 'jpg', 'gif', 'png' ), true );
}

// This passes for "shell.php.jpg" - returns true for "jpg"!

A better approach validates that the extension matches both the actual file content and the MIME type:

// SECURE: Comprehensive extension validation
function validate_extension_secure( $filename, $real_mime ) {
    $extension_map = array(
        'image/jpeg' => array( 'jpg', 'jpeg', 'jpe' ),
        'image/gif' => array( 'gif' ),
        'image/png' => array( 'png' ),
    );

    $ext = strtolower( pathinfo( $filename, PATHINFO_EXTENSION ) );
    $allowed_extensions = $extension_map[ $real_mime ] ?? array();

    // Ensure only ONE extension is used
    if ( substr_count( $filename, '.' ) > 1 ) {
        return false;
    }

    return in_array( $ext, $allowed_extensions, true );
}

This validates that:

The declared MIME type matches the actual file content
The extension is allowed for that MIME type
The filename contains only a single extension

Additionally, you should blacklist dangerous extensions that should never be uploaded:

// Block potentially dangerous extensions
$dangerous_extensions = array(
    'php', 'php3', 'php4', 'php5', 'php6', 'php7', 'phps', 'phtml',
    'phar', 'pgif', 'pjpeg', 'pjpg', 'exe', 'sh', 'bat', 'cmd',
    'asp', 'aspx', 'cgi', 'jar', 'py', 'rb', 'js'
);

if ( in_array( $ext, $dangerous_extensions, true ) ) {
    return new WP_Error( 'dangerous_extension', 'This file type is not allowed' );
}

Implementing File Size Limits Correctly

File size limits prevent attackers from consuming server resources with massive uploads. However, implementing them correctly requires checking at multiple levels.

First, WordPress defines WP_MEMORY_LIMIT and other PHP limits that affect uploads. You should enforce file size limits on both the client and server side:

// VULNERABLE: Only checking $_FILES['size']
function upload_with_size_limit_bad( $file ) {
    $max_size = 5 * MB_IN_BYTES;

    if ( $file['size'] > $max_size ) {
        return new WP_Error( 'file_too_large', 'File exceeds size limit' );
    }

    move_uploaded_file( $file['tmp_name'], '/uploads/' . $file['name'] );
    return true;
}

The problem: $_FILES['size'] can be spoofed. An attacker can modify the size value before sending the request.

// SECURE: Checking actual file size
function upload_with_size_limit_secure( $file ) {
    $max_size = 5 * MB_IN_BYTES;

    // Check reported size
    if ( $file['size'] > $max_size ) {
        return new WP_Error( 'file_too_large', 'File exceeds size limit' );
    }

    // Check actual file size on disk
    $actual_size = filesize( $file['tmp_name'] );
    if ( $actual_size > $max_size ) {
        return new WP_Error( 'file_too_large', 'File exceeds size limit' );
    }

    // Verify the file is readable and valid
    if ( ! is_readable( $file['tmp_name'] ) ) {
        return new WP_Error( 'unreadable_file', 'Unable to read file' );
    }

    move_uploaded_file( $file['tmp_name'], '/uploads/' . $file['name'] );
    return true;
}

Additionally, ensure your PHP configuration includes appropriate limits. Check these in your wp-config.php:

// Set appropriate upload limits
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

// PHP also has upload_max_filesize and post_max_size
// These should be set in php.ini or .htaccess

Using wp_handle_upload() Securely

WordPress provides wp_handle_upload(), a built-in function that handles much of the security validation for you. However, many developers still implement custom upload handlers when they should be using this function.

Here's how wp_handle_upload() should be used:

// SECURE: Proper use of wp_handle_upload
function secure_file_upload() {
    // Verify nonce and capabilities
    if ( ! isset( $_POST['nonce'] ) || ! wp_verify_nonce( $_POST['nonce'], 'upload_file' ) ) {
        wp_die( 'Security check failed' );
    }

    if ( ! current_user_can( 'upload_files' ) ) {
        wp_die( 'Insufficient permissions' );
    }

    // Only process if file was uploaded
    if ( empty( $_FILES['file'] ) ) {
        wp_die( 'No file provided' );
    }

    // Define allowed file types
    $allowed_types = array(
        'jpg|jpeg|jpe' => 'image/jpeg',
        'gif' => 'image/gif',
        'png' => 'image/png',
    );

    // Use wp_handle_upload
    $uploaded = wp_handle_upload(
        $_FILES['file'],
        array(
            'test_form' => true,
            'mimes' => $allowed_types,
        )
    );

    // Check for errors
    if ( isset( $uploaded['error'] ) ) {
        wp_die( $uploaded['error'] );
    }

    // File is now safely uploaded
    $file_path = $uploaded['file'];
    $file_url = $uploaded['url'];

    return $uploaded;
}

The wp_handle_upload() function:

Validates the file size against WordPress limits
Checks the MIME type safely
Moves the file to the uploads directory
Renames the file if necessary to avoid collisions
Applies appropriate file permissions

However, you still need to add your own validation layer on top:

// Even with wp_handle_upload, add custom validation
function upload_with_custom_validation() {
    // ... nonce and capability checks ...

    $allowed_types = array(
        'jpg|jpeg|jpe' => 'image/jpeg',
        'gif' => 'image/gif',
        'png' => 'image/png',
    );

    // Pre-upload validation
    if ( ! isset( $_FILES['file'] ) ) {
        return new WP_Error( 'no_file', 'No file provided' );
    }

    $file = $_FILES['file'];

    // Check file size before upload
    $max_size = 5 * MB_IN_BYTES;
    if ( $file['size'] > $max_size ) {
        return new WP_Error( 'file_too_large', 'File exceeds maximum size' );
    }

    // Validate with finfo
    $finfo = finfo_open( FILEINFO_MIME_TYPE );
    $real_mime = finfo_file( $finfo, $file['tmp_name'] );
    finfo_close( $finfo );

    $allowed_mimes = array_values( $allowed_types );
    if ( ! in_array( $real_mime, $allowed_mimes, true ) ) {
        return new WP_Error( 'invalid_type', 'Invalid file type' );
    }

    // Now use wp_handle_upload
    $uploaded = wp_handle_upload(
        $file,
        array(
            'test_form' => true,
            'mimes' => $allowed_types,
        )
    );

    if ( isset( $uploaded['error'] ) ) {
        return new WP_Error( 'upload_error', $uploaded['error'] );
    }

    return $uploaded;
}

Real-World Vulnerable Patterns and Fixes

Let me show you common vulnerable patterns I see in real WordPress plugins, and how to fix them.

Pattern 1: Trusting User Input for Filenames

// VULNERABLE
function save_uploaded_file() {
    if ( ! empty( $_FILES['document']['name'] ) ) {
        $target = '/uploads/' . $_FILES['document']['name'];
        move_uploaded_file( $_FILES['document']['tmp_name'], $target );
    }
}

An attacker could upload a file with a path traversal name like ../../wp-config.php or ../../../shell.php.

// SECURE: Sanitize and generate safe filenames
function save_uploaded_file_secure() {
    if ( empty( $_FILES['document'] ) ) {
        return new WP_Error( 'no_file', 'No file provided' );
    }

    $file = $_FILES['document'];

    // Generate a safe, unpredictable filename
    $ext = strtolower( pathinfo( $file['name'], PATHINFO_EXTENSION ) );
    $safe_name = wp_hash( $file['name'] . time() ) . '.' . $ext;

    $upload_dir = wp_upload_dir();
    $target = $upload_dir['basedir'] . '/' . $safe_name;

    if ( ! move_uploaded_file( $file['tmp_name'], $target ) ) {
        return new WP_Error( 'upload_failed', 'Failed to upload file' );
    }

    return array( 'file' => $target, 'name' => $safe_name );
}

Pattern 2: Executing Uploaded Files

// VULNERABLE: Serving uploaded PHP files
function serve_uploaded_file() {
    $file = $_GET['file'];
    include '/uploads/' . $file;
}

This allows an attacker to execute any uploaded PHP file.

// SECURE: Serve files as downloads, never execute
function serve_uploaded_file_secure() {
    if ( ! isset( $_GET['file_id'] ) ) {
        wp_die( 'File not found' );
    }

    // Get file path from database, never from user input
    $file_id = intval( $_GET['file_id'] );
    $file_path = get_file_path_from_db( $file_id );

    // Verify file exists and is within uploads directory
    $upload_dir = wp_upload_dir();
    $real_path = realpath( $file_path );

    if ( strpos( $real_path, $upload_dir['basedir'] ) !== 0 ) {
        wp_die( 'Invalid file' );
    }

    // Force download, don't execute
    header( 'Content-Disposition: attachment; filename=' . basename( $file_path ) );
    header( 'Content-Type: application/octet-stream' );
    readfile( $real_path );
    exit;
}

Pattern 3: Missing Nonce Checks

// VULNERABLE: No nonce verification
if ( ! empty( $_FILES['file'] ) ) {
    move_uploaded_file( $_FILES['file']['tmp_name'], '/uploads/file.jpg' );
}

An attacker can trick authenticated users into uploading files via CSRF.

// SECURE: Nonce verification required
if ( ! empty( $_POST['nonce'] ) && wp_verify_nonce( $_POST['nonce'], 'upload_file' ) ) {
    if ( ! empty( $_FILES['file'] ) ) {
        move_uploaded_file( $_FILES['file']['tmp_name'], '/uploads/file.jpg' );
    }
} else {
    wp_die( 'Security check failed' );
}

These patterns represent real vulnerabilities I've encountered in production WordPress installations. By understanding what makes them vulnerable, you can write better, more secure code.

Building a Comprehensive Upload Handler

Let me show you what a truly secure, production-ready file upload handler looks like when you combine all these principles:

<?php
/**
 * Secure file upload handler
 */

class Secure_File_Uploader {

    private $allowed_types = array(
        'jpg|jpeg|jpe' => 'image/jpeg',
        'gif' => 'image/gif',
        'png' => 'image/png',
    );

    private $max_file_size = 0;

    public function __construct() {
        $this->max_file_size = 5 * MB_IN_BYTES;
    }

    /**
     * Main upload handler
     */
    public function handle_upload( $file, $nonce ) {
        // 1. Verify nonce
        if ( ! wp_verify_nonce( $nonce, 'upload_file' ) ) {
            return new WP_Error( 'invalid_nonce', 'Security check failed' );
        }

        // 2. Check capabilities
        if ( ! current_user_can( 'upload_files' ) ) {
            return new WP_Error( 'insufficient_permissions', 'You cannot upload files' );
        }

        // 3. Validate file structure
        if ( ! isset( $file['tmp_name'], $file['name'], $file['size'] ) ) {
            return new WP_Error( 'invalid_file', 'Invalid file data' );
        }

        // 4. Check file size
        $size_check = $this->validate_file_size( $file );
        if ( is_wp_error( $size_check ) ) {
            return $size_check;
        }

        // 5. Validate MIME type
        $mime_check = $this->validate_mime_type( $file );
        if ( is_wp_error( $mime_check ) ) {
            return $mime_check;
        }

        // 6. Validate extension
        $ext_check = $this->validate_extension( $file['name'], $mime_check );
        if ( is_wp_error( $ext_check ) ) {
            return $ext_check;
        }

        // 7. Use wp_handle_upload
        $uploaded = wp_handle_upload(
            $file,
            array(
                'test_form' => true,
                'mimes' => $this->allowed_types,
            )
        );

        if ( isset( $uploaded['error'] ) ) {
            return new WP_Error( 'upload_error', $uploaded['error'] );
        }

        return $uploaded;
    }

    private function validate_file_size( $file ) {
        $size = (int) $file['size'];

        if ( $size > $this->max_file_size ) {
            return new WP_Error( 'file_too_large', 'File exceeds maximum size' );
        }

        $actual_size = filesize( $file['tmp_name'] );
        if ( $actual_size > $this->max_file_size ) {
            return new WP_Error( 'file_too_large', 'File exceeds maximum size' );
        }

        return true;
    }

    private function validate_mime_type( $file ) {
        if ( ! function_exists( 'finfo_file' ) ) {
            return new WP_Error( 'no_finfo', 'Server missing required functions' );
        }

        $finfo = finfo_open( FILEINFO_MIME_TYPE );
        $real_mime = finfo_file( $finfo, $file['tmp_name'] );
        finfo_close( $finfo );

        $allowed_mimes = array_values( $this->allowed_types );
        if ( ! in_array( $real_mime, $allowed_mimes, true ) ) {
            return new WP_Error( 'invalid_mime', 'Invalid file type' );
        }

        return $real_mime;
    }

    private function validate_extension( $filename, $real_mime ) {
        $ext = strtolower( pathinfo( $filename, PATHINFO_EXTENSION ) );

        // Block multiple extensions
        if ( substr_count( $filename, '.' ) > 1 ) {
            return new WP_Error( 'suspicious_extension', 'Invalid filename' );
        }

        $allowed_ext = $this->allowed_types[ $ext ] ?? null;
        if ( $allowed_ext !== $real_mime ) {
            return new WP_Error( 'extension_mismatch', 'File extension does not match content' );
        }

        return true;
    }
}

This comprehensive class implements all the security principles we've discussed:

Nonce verification
Capability checking
File size validation at multiple levels
MIME type detection based on actual file content
Extension validation with format checking
Integration with WordPress's wp_handle_upload()

To use this in your plugin or theme:

$uploader = new Secure_File_Uploader();
$result = $uploader->handle_upload( $_FILES['document'], $_POST['nonce'] ?? '' );

if ( is_wp_error( $result ) ) {
    wp_die( $result->get_error_message() );
}

// File is now safely uploaded
echo 'File uploaded successfully: ' . esc_url( $result['url'] );

When implementing file uploads in WordPress, remember that security is not a single check—it's a layered defense. You need to validate MIME types, extensions, and actual file content. You need to check file sizes at multiple levels. You need to verify user capabilities and prevent CSRF attacks with nonces. And you should always use WordPress's built-in functions like wp_handle_upload() when possible.

That said, thoroughly auditing your file upload implementations is challenging without specialized tools. WP HealthKit can help you identify vulnerable file upload patterns in your plugins and themes, highlighting exactly where your implementations fall short. With automated scanning, you can catch these issues before they become production problems.

Additional Resources

For a comprehensive view of how WP HealthKit approaches plugin analysis, explore our 17 verification layers or browse the plugin directory to see real audit scores. Ready to check your own plugin? Run a free audit now.

Frequently Asked Questions

What's the difference between MIME type and file extension?

MIME types describe the actual content of a file (like image/jpeg), while extensions are just filename suffixes (like .jpg). A file can have any extension regardless of its actual content. An attacker can upload a PHP file with a .jpg extension, which is why you must validate the actual file content using functions like finfo_file().

Can I rely on the `$_FILES['type']` variable for MIME type validation?

No, absolutely not. The $_FILES['type'] variable is sent by the browser and can be easily spoofed. An attacker can modify their request to claim any MIME type they want. Always validate the actual file content using finfo_file() or similar functions.

Why is `wp_handle_upload()` important for file uploads?

wp_handle_upload() is WordPress's standardized file upload function that handles many security validations automatically, including MIME type checking, file moving, and permission management. Using it ensures you follow WordPress best practices and benefit from core security improvements. However, you should still add custom validation on top of it.

How do I prevent path traversal attacks in file uploads?

Never use user-supplied filenames directly in file paths. Always generate new, unpredictable filenames using functions like wp_hash() combined with timestamps. Verify that the final file path stays within the intended uploads directory using realpath() and checking the path prefix.

What file types should I always block?

Block executable file types including PHP variants (.php, .php3-7, .phtml), scripts (.sh, .py, .rb), compiled files (.exe, .jar), and server-side includes (.asp, .aspx). Use a blacklist as an additional layer even when you have an explicit whitelist of allowed types.

Should I store uploaded files in the web root?

Ideally, no. Files in the web root are directly accessible and can potentially be executed depending on server configuration. Consider storing uploads outside the web root and serving them through a PHP script that validates access permissions and forces downloads instead of execution.

File upload security in WordPress is a critical skill that separates secure plugins from vulnerable ones. By implementing the defense-in-depth approach outlined here—validating MIME types and actual file content, checking extensions carefully, enforcing file size limits, and using WordPress's built-in functions—you can significantly reduce your attack surface.

Ready to audit your plugin's file upload security? Upload your plugin to WP HealthKit for a comprehensive security scan that identifies vulnerable upload handlers and other security issues in your code.

Explore WP HealthKit's security features and see how our automated audits can catch file upload vulnerabilities before they reach production.

WordPress File Upload Security: A Validation Deep Dive

Table of Contents

Why File Upload Security Matters

MIME Type Validation

Extension-Based Validation and Double Extension Attacks

Implementing File Size Limits Correctly

Using wp_handle_upload() Securely

Real-World Vulnerable Patterns and Fixes

Building a Comprehensive Upload Handler

Additional Resources

Frequently Asked Questions

What's the difference between MIME type and file extension?

Can I rely on the `$_FILES['type']` variable for MIME type validation?

Why is `wp_handle_upload()` important for file uploads?

How do I prevent path traversal attacks in file uploads?

What file types should I always block?

Should I store uploaded files in the web root?

Ready to audit your plugin?

Related Articles

WordPress Plugin Penetration Testing: A DIY Pentest Guide

WordPress Cross-Plugin Communication: Security Patterns

WordPress AI Plugin Security: LLM Integration Guide

Comments

Table of Contents

Why File Upload Security Matters

MIME Type Validation

Extension-Based Validation and Double Extension Attacks

Implementing File Size Limits Correctly

Using wp_handle_upload() Securely

Real-World Vulnerable Patterns and Fixes

Building a Comprehensive Upload Handler

Additional Resources

Frequently Asked Questions

What's the difference between MIME type and file extension?

Can I rely on the $_FILES['type'] variable for MIME type validation?

Why is wp_handle_upload() important for file uploads?

How do I prevent path traversal attacks in file uploads?

What file types should I always block?

Should I store uploaded files in the web root?

Ready to audit your plugin?

Related Articles

WordPress Plugin Penetration Testing: A DIY Pentest Guide

WordPress Cross-Plugin Communication: Security Patterns

WordPress AI Plugin Security: LLM Integration Guide

Comments

Can I rely on the `$_FILES['type']` variable for MIME type validation?

Why is `wp_handle_upload()` important for file uploads?