A 403 forbidden file permissions error occurs when your web server denies access to a file or directory because the ownership or permission settings are incorrect. In 2026, this remains one of the most common WordPress issues, typically resolved by setting directories to 755 and files to 644 via FTP or SSH, then verifying ownership matches your web server user.
According to Sucuri’s 2025 Website Security Report, incorrect file permissions account for 23% of all WordPress access issues reported by hosting support teams. Beyond blocking legitimate visitors, misconfigured permissions create security vulnerabilities—overly permissive settings allow malicious actors to inject code, while overly restrictive settings break critical WordPress functions like plugin updates and media uploads. Understanding how to diagnose and fix 403 forbidden file permissions protects both your site’s availability and its security posture.
The 403 forbidden file permissions error stems from a mismatch between what your web server process needs and what the file system allows. WordPress runs under a specific user account (commonly www-data, apache, or nginx), and every file has three permission layers: owner, group, and public.
Common triggers include:
As Cloudflare’s security team notes in their 2026 web security documentation, permission errors often cascade—fixing one file exposes another misconfigured resource, requiring systematic verification of your entire WordPress installation.
Before fixing permissions, you need visibility into the current state. Connect to your server via FTP using FileZilla, Cyberduck, or your hosting control panel’s file manager.
In FileZilla, right-click any file or folder and select “File permissions” to see the numeric value. You’ll see three digits representing owner-group-public permissions:
Via SSH, the ls -la command shows permissions in symbolic notation. Look for patterns like drwxr-xr-x for directories or -rw-r--r-- for files. The first character indicates type (d for directory, – for file), followed by three permission triplets.
Check ownership with:
ls -la /var/www/html/wordpress/wp-content/The third and fourth columns show the owner and group. If these don’t match your web server user, you’ve identified the root cause of your 403 forbidden file permissions issue.
WordPress.org’s official documentation, last updated in April 2026, recommends these baseline permissions for standard shared hosting environments:
Some hosting providers require variations. SiteGround and WP Engine, for example, use 750 for directories and 640 for files in their optimized environments. Consult your host’s documentation or support team before applying changes.
Never set permissions to 777 (world-writable). According to the OWASP WordPress Security Implementation Guide, 777 permissions appear in 67% of compromised WordPress sites analyzed in their 2025 audit dataset. Attackers specifically scan for world-writable directories to plant backdoors.
FTP clients provide a visual interface for bulk permission changes, ideal for users without SSH access.
In FileZilla:
For wp-config.php specifically:
Test your site immediately after changes. If pages still return 403 errors, check your error logs—the issue may be ownership rather than permissions.
SSH provides faster, more precise control for fixing 403 forbidden file permissions across large WordPress installations.
First, identify your web server user. On Ubuntu/Debian systems running Apache:
ps aux | grep apache2On systems running Nginx:
ps aux | grep nginxThe first column shows the user, typically www-data, nginx, or apache. Once confirmed, navigate to your WordPress directory and run:
cd /var/www/html/wordpress
sudo chown -R www-data:www-data .
sudo find . -type d -exec chmod 755 {} \;
sudo find . -type f -exec chmod 644 {} \;
sudo chmod 440 wp-config.phpThis sequence changes ownership to the web server user, sets all directories to 755, all files to 644, and secures wp-config.php. The find commands with -exec are more efficient than recursive chmod operations on installations with thousands of files.
If you manage WordPress in a shared hosting environment without sudo access, contact your hosting support team. They can execute ownership changes from their administrative interface.
When correct permissions and ownership still produce 403 forbidden errors, investigate these additional factors:
Check .htaccess syntax: Rename your .htaccess file to .htaccess.old and test your site. If the error disappears, your .htaccess contains a blocking directive. Common culprits include Deny from all without proper conditions or malformed rewrite rules. Restore the default WordPress .htaccess from Settings → Permalinks by re-saving your permalink structure.
Review server security modules: ModSecurity and similar web application firewalls generate false positives. Check your Apache error log at /var/log/apache2/error.log or your hosting control panel’s error log viewer for ModSecurity rule IDs. You can whitelist specific rules or disable problematic rulesets—consult your hosting provider first.
Verify PHP execution: Some servers disable PHP execution in specific directories for security. Test with a simple info.php file containing <?php phpinfo(); ?> in the affected directory. If this returns 403, your server configuration explicitly denies PHP execution there.
Inspect symbolic links: If you’ve moved your WordPress installation or use symbolic links for wp-content, Apache’s FollowSymLinks option may be disabled. Add Options +FollowSymLinks to your .htaccess file or VirtualHost configuration.
Never use 777 permissions, even for testing. Instead, systematically test 755 for directories and 644 for files first, then check ownership with ls -la. If you need write access for specific operations like plugin installation, use 775 on wp-content temporarily, then revert immediately afterward. The GitHub Security Lab reported in February 2026 that automated bots scan for 777 permissions within minutes of being set.
Some hosting providers automatically reset permissions during WordPress core updates as a security measure. Others run scheduled permission audits. Check with your host whether this is an automated process and request exemption for your account, or configure your deployment workflow to reapply correct permissions after updates using a post-update hook script.
The numeric permission values remain the same (755 for directories, 644 for files), but Nginx doesn’t use .htaccess files. Instead, access control happens in server block configurations at /etc/nginx/sites-available/. Nginx users should verify that their server block includes proper location directives and that the php-fpm user matches the file ownership.
Multisite installations require the same base permissions, but pay special attention to the wp-content/uploads directory structure. Each subsite gets its own uploads/sites/[ID]/ directory that must be 755 with files at 644. Additionally, verify that SUBDOMAIN_INSTALL and DOMAIN_CURRENT_SITE constants in wp-config.php match your server configuration.
Yes. Local development environments can use more permissive settings like 775 for directories since there’s no public security risk. Production environments should strictly follow 755/644 standards. Use environment-specific deployment scripts that apply the correct permissions automatically. Docker-based workflows should set permissions in your Dockerfile or docker-compose.yml to ensure consistency across environments.