A WordPress 403 Forbidden error means the server received your request but refused to allow access. It can appear on the front end, at /wp-admin/, during a media upload, when saving a post, or on a specific plugin or theme path.
The message does not usually point to a damaged WordPress database. More often, access is being blocked by file permissions, ownership, a security plugin, an .htaccess rule, ModSecurity, or another server-level control. The most reliable fix is to identify which URL and request type are failing, then test the likely source without weakening the entire site.
Make a backup before editing files or server settings. For a business or store, consider involving a WordPress developer if you do not have server access or if the error affects checkout. A structured WordPress maintenance arrangement can also help with recurring troubleshooting and documented fixes.
Start by locating the blocked request
Test the home page, a regular post, the login page, the dashboard, media uploads, and the URL that originally produced the error. Use a private browser window and, if possible, another network. This helps separate a site-wide block from an IP-specific or browser-specific problem.
The pattern often provides a useful starting point:
- Every page returns 403: investigate server rules, domain configuration, file ownership, permissions, or a web application firewall.
- Only
/wp-admin/or login is blocked: check security plugins, IP restrictions, and rules targeting administrator URLs. - Only uploads or one plugin path fails: inspect that directory’s permissions and ownership, along with security rules for the path.
- Only POST requests fail: ModSecurity or another firewall may be rejecting form data, REST requests, or AJAX calls.
Check WordPress file permissions and ownership
Incorrect permissions can prevent the web server from reading WordPress files or writing to directories such as wp-content/uploads. In cPanel, open File Manager, locate the WordPress installation, right-click a file or folder, and select Change Permissions.
Common starting points are:
- Directories:
755 - Files:
644 wp-config.php: often600or640, depending on the hosting setup
These values are recommendations, not universal requirements. Hosting configurations differ, and correct numeric permissions will not help if the files belong to the wrong system user or group.
Do not change everything to 777. That grants excessive write access and can create a serious security weakness. If you use SSH, you can inspect permissions with:
find /path/to/wordpress -type d -exec chmod 755 {} \;
find /path/to/wordpress -type f -exec chmod 644 {} \;Replace the path with the actual WordPress directory, and confirm your host’s ownership recommendations before running broad commands. On managed hosting or a VPS, ask the provider or a developer to check ownership rather than applying an unverified recursive chown command.
Test whether a security plugin is blocking the request
Security plugins may block login attempts, suspicious query strings, REST API requests, XML-RPC traffic, or particular IP addresses. A false positive can look identical to a server-generated 403.
Open the plugin’s firewall, blocked-IP, live traffic, or audit-log area and search for an event at the same time as the failed request. If you cannot reach the dashboard, use File Manager or FTP to rename the suspected plugin directory inside wp-content/plugins/. Renaming the directory temporarily disables the plugin without deleting its settings.
Test the URL again. If the error disappears, restore the original folder name, log in, and adjust the specific rule. Whitelist an IP only when you understand the risk and it is appropriate for your setup. Do not leave every security feature disabled as a permanent workaround.
If more than one plugin changed recently, use a careful plugin-conflict triage workflow to isolate the change.
Rebuild the .htaccess file carefully
On Apache hosting, a malformed or overly restrictive .htaccess file can deny visitors before WordPress loads. The file may be hidden, so enable Show Hidden Files in File Manager.
Download a copy first, then rename .htaccess to something like .htaccess-backup. If the site becomes accessible, log in to WordPress and open Settings > Permalinks. Click Save Changes without changing the permalink setting. WordPress will usually write fresh rewrite rules.
A basic WordPress file often resembles this:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressDo not replace a production file blindly. Custom redirects, password protection, host-specific directives, and security rules may be required. If the regenerated file does not help, restore the backup and continue with the server and security checks.
Ask the host to investigate ModSecurity
ModSecurity is a web application firewall used by many hosting providers. It examines requests for patterns associated with attacks. Legitimate actions such as editing content, uploading files, or submitting a WooCommerce order can occasionally trigger a rule.
Look for a ModSecurity or web application firewall section in cPanel. Some hosts display blocked requests and rule IDs; others need to inspect the audit log for you. Send support the exact URL, approximate time, IP address, and action that produced the 403. Ask which rule was triggered and whether a narrow exception is possible. Disabling ModSecurity for the entire account should not be the default solution.
Read the access and error logs
Server logs can show whether the request was denied by permissions, rewrite rules, ownership, or a security module. In cPanel, check Metrics > Errors, Raw Access, or the host’s log viewer. On a VPS, Apache and Nginx log locations vary by configuration.
An access-log entry confirms the requested path, method, and response code. The error log may identify a denied file, an ownership mismatch, an .htaccess directive, or a ModSecurity rule. Compare a successful request with the failing one and note whether the problem affects one URL, one IP address, or all visitors.
Do not publish complete logs. They may contain IP addresses, query strings, usernames, and internal paths. Share only the relevant lines with your hosting provider or developer.
Clear caches and review recent changes
A CDN or page-cache layer may continue serving a cached 403 after the underlying issue is fixed. Clear the relevant page, object, server, and CDN caches after changing firewall or rewrite settings.
Then review recent changes to plugins, themes, DNS, SSL, hosting, PHP versions, and server configuration. If the issue began after a migration, compare file ownership, permissions, virtual-host settings, and rewrite rules between the old and new environments.
If the 403 appears alongside broader server failures, review this guide to fix WordPress 500 errors. Permission and configuration problems can sometimes produce more than one type of error.
When to involve a WordPress developer
Professional help is sensible when you lack server access, the error affects a live WooCommerce checkout, logs point to ModSecurity or Nginx, or changing permissions could expose sensitive files. A developer can review the server configuration, security-plugin settings, and logs while testing the front end, dashboard, REST API, uploads, and checkout.
For agencies and site owners, documented emergency troubleshooting or ongoing WordPress maintenance can be safer than repeated one-click changes, especially when several systems are involved.
Frequently asked questions
Does a 403 error mean WordPress has been hacked?
Not necessarily. Incorrect permissions, firewall rules, and a bad .htaccess directive are common causes. If you see unfamiliar files, users, or administrator activity, review the security logs and scan the site as part of a broader investigation.
Should I change WordPress permissions to 777?
No. 777 allows anyone with the relevant access to read, write, and execute files or directories. Use restrictive permissions and correct ownership based on your hosting configuration.
Can clearing the cache fix a WordPress 403?
It can remove a cached 403 from a CDN or page-cache layer, but it will not correct the server or firewall rule that generated the original response.
Why does only one plugin produce a 403?
The plugin may trigger ModSecurity, a security-plugin rule, or a directory-specific permission problem. Reproduce the error while checking the relevant logs so you can identify the exact block.
Conclusion
Fix a WordPress 403 Forbidden error by narrowing down the affected request, checking permissions and ownership, testing security plugins, reviewing .htaccess, and consulting ModSecurity and server logs. Avoid blanket permission changes and broad firewall disabling. A targeted diagnosis is safer and reduces the chance of creating a second security problem.