How to Fix a 403 Forbidden Error

A 403 Forbidden error means the web server understood the request, but it refuses to allow access to the requested resource. In hosting environments this is usually caused by file permissions, a missing index file, an incorrect .htaccess rule, security restrictions, or a problem with the web server configuration in Apache or a control panel such as Plesk.

If you manage a website on a hosting platform, a 403 error is often fixable without changing the application itself. The key is to identify whether the block is coming from file access rules, directory settings, security software, or a misconfiguration after a migration or update. The steps below are written for common shared hosting, managed hosting, and VPS environments used across the European market.

What a 403 Forbidden error means

HTTP status code 403 indicates that access is denied. Unlike a 404 error, the server is aware that the resource exists or should exist, but it will not serve it to the visitor. In practice, this can happen for several reasons:

• The directory or file permissions are too restrictive.
• The web server cannot find a valid index file such as index.php or index.html.
• A .htaccess rule blocks access.
• An IP address, country, user agent, or referrer is denied by security rules.
• The domain points to the wrong document root or an empty directory.
• Directory listing is disabled and no index file exists.
• File ownership is incorrect after a migration or deployment.

On a hosting platform, the most common cause is usually permissions or a broken configuration file. If the error appears after a site update, plugin install, or content migration, the issue is often in the application configuration or in a security rule added automatically.

Common symptoms you may see

A 403 error does not always look the same. Depending on the server and browser, you may see:

• “403 Forbidden”
• “Access denied”
• “You don’t have permission to access this resource”
• A blank page with a permission-related message
• A custom error page from the hosting provider or CMS

Sometimes only one directory or one file is blocked, while the rest of the website works normally. In other cases, the homepage itself returns a 403 because the server cannot load the default index file.

Step 1: Check whether the issue affects the whole site or only one page

Start by testing a few URLs:

• The homepage
• A subpage that normally works
• A file such as an image or PDF
• A directory path without a filename

If only one folder returns 403, the problem is usually local to that directory. If the entire domain is blocked, the issue is more likely in the document root, DNS target, virtual host configuration, or a global security rule.

Also test the site in an incognito window and from a different network. A browser cache issue is rare for 403 errors, but an IP-based restriction or geoblock can affect only certain visitors.

Step 2: Verify file and folder permissions

Incorrect permissions are one of the most frequent causes of 403 Forbidden errors on Apache-based hosting. Typical permissions are:

• Directories: 755
• Files: 644

These values allow the web server to read website files while preventing unsafe write access. If a directory is set to 700 or a file is set to 600, Apache may refuse access. If permissions are too open, the site may still load, but that creates a security risk and is not recommended.

How to check permissions in a hosting control panel

In a control panel such as Plesk, open the file manager and review the permissions for the website directory. Look for folders that contain the site content, especially the document root. Ensure the web server user has read access to the files.

How to check permissions by SSH

If you have shell access, you can inspect the permission values and ownership. A common symptom of a problem is a directory that does not grant execute permission to the web server user or a file that is not readable.

After adjusting permissions, reload the site and test again. If the issue remains, move to the next step rather than changing permissions randomly across the whole account.

Step 3: Confirm that a valid index file exists

When a browser opens a directory path, Apache tries to serve a default file such as index.php, index.html, or another filename defined in the server configuration. If no index file exists and directory listing is disabled, the server may return 403.

This often happens after:

• Deleting or renaming the homepage file
• Deploying a new version of a site with a different document structure
• Pointing the domain to the wrong folder
• Using a CMS that expects index.php but the file is missing

Check the document root for a valid homepage file. On many hosting platforms, the directory might be named httpdocs, public_html, or a custom application folder. Make sure the index file is located in the correct place and that the domain is mapped to that directory.

Step 4: Review .htaccess rules

The .htaccess file can trigger a 403 error if it contains a rule that denies access, rewrites URLs incorrectly, or includes unsupported directives. This is particularly common after CMS migrations, plugin updates, or manual edits.

To test whether .htaccess is the cause:

1. Back up the existing .htaccess file.
2. Rename it temporarily, for example to .htaccess.backup.
3. Reload the website.

If the site starts working, the problem is inside .htaccess. Restore the file and review it line by line. Look for:

• Deny from all or Require all denied
• Incorrect rewrite rules
• Rules that block specific paths accidentally
• Old directives from legacy Apache versions
• Security rules copied from another environment

For CMS platforms, a fresh default .htaccess file may be safer than a manually edited one. If you use WordPress, Drupal, Joomla, or another application, compare your file with the official recommended configuration for that platform.

Step 5: Check ownership and deployment context

Permissions are only part of the story. File ownership must also be correct. If files were uploaded by a different system user, deployed from a staging environment, or restored from a backup, Apache may not be able to read them even if the permission numbers look correct.

This is especially relevant on managed hosting platforms and VPS systems where multiple users, PHP handlers, or deployment tools are involved. A site can return 403 after:

• A migration from another provider
• A Git deployment
• A restore from backup
• A file sync from a local machine or CI pipeline

Make sure the website files belong to the correct system user and web server group used by your hosting environment. If you are not sure what ownership should be, compare the site with a working account on the same server or contact support with the account name and affected path.

Step 6: Inspect security extensions and blocking rules

Security tools can correctly block malicious requests, but they can also create false positives. On a hosting platform, a 403 error may be caused by:

• ModSecurity rules
• Firewall restrictions
• Country-based access controls
• IP deny lists
• Bot protection or rate limiting
• Application security plugins

If the site works from one network but not another, compare the blocked IPs and look for access restrictions in the control panel. In Plesk, for example, security tools may be visible through extensions or subscription settings. If ModSecurity is enabled, a recent rule may be blocking a legitimate request from your application, form submission, or admin area.

When reviewing security blocks, avoid disabling all protection permanently. Instead, identify the exact rule or source of the denial. If needed, whitelist the specific path or IP address used for administration, monitoring, or deployment.

Step 7: Verify the domain mapping and document root

A 403 error can occur when the domain points to a directory that exists but does not contain website files or does not permit access. This may happen if the domain is mapped to the wrong document root after a change in hosting setup.

Check the following:

• The domain is attached to the correct subscription or site configuration.
• The document root points to the folder that contains the application files.
• The public web root is not nested inside another protected directory.
• The website was not accidentally moved into a staging or private folder.

In many hosting panels, the web root and the file system path are shown separately. Confirm that both match the intended site structure. If the root folder is empty or only contains temporary files, the server may respond with 403 when directory listing is disabled.

Step 8: Check for missing directory index configuration

Apache uses a directory index setting to determine which file to display first. If the server is configured to allow only specific index filenames and your site uses a different one, the server may refuse access.

For example, if the application expects index.php but the server looks only for index.html, the result can be a 403 for the folder URL. This is common after custom hosting changes or migrations from another environment.

If you administer the server, review the Apache directory index configuration. If you use managed hosting, check whether the site files are in the expected format for the platform. CMS-based sites typically need a PHP-based index file in the document root.

Step 9: Clear caches and retest

Although caching is not the usual cause of a 403, caches can preserve outdated rules, especially after a migration or permission fix. Clear these layers when testing:

• Browser cache
• CMS cache
• Reverse proxy cache, if used
• Hosting platform cache or opcode cache

After clearing caches, test the URL again in a private browser window. If you operate a multilingual or European-facing site, test from multiple locations as well, because access restrictions may behave differently depending on the visitor’s region.

Step 10: Read the error logs

Error logs are often the fastest way to find the exact reason for a 403. On a hosting platform, Apache logs may show whether access was denied by permissions, a .htaccess rule, or a security module.

Look for messages such as:

• client denied by server configuration
• permission denied
• directory index forbidden by options directive
• access forbidden by rule
• file does not exist or no index file

In Plesk and similar control panels, logs are often available per domain. Check both the access log and the error log for the exact timestamp when the error occurred. This is especially useful if the problem started after a plugin update, deployment, or security change.

How to fix a 403 Forbidden error in Plesk

If your website is hosted in Plesk, use the following checklist:

• Confirm the domain points to the correct document root.
• Check that the main site files are inside the web root.
• Verify that file and folder permissions are not too restrictive.
• Review the .htaccess file in the domain root.
• Check whether ModSecurity or another security layer is blocking access.
• Inspect the domain logs for the exact Apache error.

Plesk also makes it easier to identify whether the issue is at the subscription level, file system level, or web server level. If the site uses additional PHP handlers, frameworks, or application installers, make sure the app files are compatible with the selected configuration.

How to fix a 403 Forbidden error on Apache

On Apache, the most important areas to verify are permissions, directory directives, and access rules. Review these points:

• DocumentRoot points to the correct folder.
• Directory blocks allow access to the site path.
• Require all granted is present where needed.
• There is a valid index file in the directory.
• No conflicting .htaccess rule blocks the path.

If the site was recently moved from one server to another, compare the Apache configuration on the old and new environment. Even a small difference in directory policy can cause a previously working site to start returning 403.

Special cases that often cause 403 errors

Protected admin folders

Many applications intentionally protect admin directories, image upload folders, or private storage locations. If those folders are directly requested in the browser, a 403 may be expected. Confirm whether the error is actually a security feature rather than a fault.

Missing trailing slash

Some directories require a trailing slash to resolve correctly. For example, a folder URL may behave differently from a file URL. Rewrite rules should handle this consistently, but a broken rule can result in access denied behavior.

Hotlink protection

If hotlink protection is enabled, external sites may receive a 403 when trying to load images or assets. This is normal for unauthorized referrers, but it can also break legitimate embedding if the allowed domains are not configured correctly.

Maintenance or firewall rules

Temporary maintenance pages, WAF rules, or geo restrictions can make a website appear blocked. If the site is under active maintenance or deployment, verify that the correct rules are removed when the work is finished.

Practical troubleshooting checklist

Use this checklist in order:

1. Confirm whether the 403 affects one page or the whole site.
2. Check file and folder permissions.
3. Verify the site has a valid index file.
4. Temporarily disable or rename .htaccess to test it.
5. Review ownership after migrations or restores.
6. Check security tools, firewalls, and ModSecurity.
7. Confirm the domain points to the correct document root.
8. Clear caches and retest.
9. Inspect Apache and control panel logs.

If the problem started immediately after a change, reverse the last change first. That is usually faster than searching the full configuration at random.

When you should contact hosting support

Contact hosting support if you cannot access logs, if the issue appears at server level, or if the problem remains after checking permissions and .htaccess. It is especially useful to provide:

• The full URL affected by the error.
• The time when the issue started.
• Any recent changes to files, plugins, or DNS.
• Screenshots of the browser error.
• The exact text from the Apache error log.

On managed hosting, support can quickly confirm whether the block is coming from a server policy, a security rule, or a file system issue. That saves time compared with changing settings blindly.

FAQ

Is a 403 error the same as a 404 error?

No. A 404 means the server cannot find the resource. A 403 means the server knows the resource exists or should exist, but access is denied.

Can a 403 error be caused by DNS?

Indirectly, yes. If the domain points to the wrong hosting account or wrong document root, you may see a 403 instead of the expected site. DNS itself does not generate 403, but wrong routing can lead to it.

Why does my site work for me but not for visitors?

This often points to IP-based blocking, country restrictions, browser differences, or caching. Check security rules and test from another network.

Will changing permissions to 777 fix the problem?

It might temporarily hide a permissions issue, but it is not a safe fix. Use proper permissions such as 755 for directories and 644 for files.

Can a plugin or module create a 403 error?

Yes. Security plugins, redirect modules, caching plugins, and access control extensions can all block legitimate requests if configured incorrectly.

What is the fastest first test for a 403 error?

Check permissions and rename .htaccess temporarily. Those two steps solve a large number of 403 issues on Apache-based hosting.

Conclusion

A 403 Forbidden error is usually a sign that the web server is preventing access due to permissions, configuration, or security rules. In most hosting environments, the most effective fix is to check file permissions, confirm the presence of a valid index file, review .htaccess, verify ownership, and inspect server logs. On platforms such as Plesk and Apache-based hosting, these checks quickly narrow down whether the problem is in the application, the file system, or the web server configuration.

Once you identify the source of the denial, the fix is usually straightforward and permanent. If the error appeared after a migration, deployment, or security change, focus first on the most recent change and validate the document root, permissions, and access rules before making broader adjustments.