Fix 403 Forbidden

If your website displays the error message 403 Forbidden or rather 403 Access Denied displayed, the web server can generally reach the requested resource, but refuses access to it.

Therefore, the cause is often not the domain itself, but rather access rules, file permissions, a .htaccess-file or a security feature.

In this guide, we will show you how to systematically investigate a 403 error in CURIAWEB web hosting and resolve the most common causes.

Important: Do not change file permissions at the same time, .htaccess, ModSecurity, and other security settings. Check one potential cause after another. That is the only way to determine what is actually causing the 403 error.

What does 403 Forbidden mean? #

The HTTP status code 403 simplified means:

Request reaches the web server
        ↓
Requested resource is recognized
        ↓
Access is not allowed
        ↓
403 Forbidden

This is what distinguishes a 403 error from a classic 404 error, for example.

Error	Simply put, he
403 Forbidden	Access to the resource is denied.
404 Not Found	Requested resource was not found
500 Internal Server Error	Server-side processing failed
503 Service Unavailable	Service temporarily unable to process the request

What can a 403 error look like? #

Depending on the application and web server, the visible message may be formulated differently.

Examples are:

403 Forbidden

Forbidden

Access Denied

You don't have permission to access this resource.

The HTTP status code is crucial 403.

403 on the whole website or just on one URL? #

Before changing settings, you should narrow down the error pattern.

Check, for example:

• Is the entire website affected?
• Just a single page?
• Only the WordPress admin area?
• Just one file or one directory?
• Just a form or a specific action?
• Only your own internet connection or rather your IP address?

This distinction already provides important clues as to the possible cause.

1. Note the affected URL precisely #

First, note the URL where the error occurs.

For example:

https://example.ch

or:

https://example.ch/wp-admin

or:

https://example.ch/download/datei.pdf

If only a specific URL is affected, you should not immediately change the configuration of the entire website.

2. Test for errors in a private browser window #

Also open the affected URL in a private or incognito window.

This allows you to at least more easily rule out certain local browser, cookie, or session effects.

However, a private browser window does not bypass a server-side IP ban.

3. Check if only your IP address is affected #

If the website shows a 403 error for you, but works for other people or via a different internet connection, an IP-related block may be involved.

For example, you can compare:

own internet connection → 403
mobile connection        → website works

This is a clear indication that the website is not generally blocked.

Practical Tip: A test via a second internet connection can be very helpful in the event of a 403 error. Do not prematurely disable the website's security features for this purpose.

4. Check cPanel Error Log #

Open in CURIAWEB-cPanel:

Measured values → Errors

Check if a matching entry exists at the time of the 403 error.

We explain how to systematically evaluate error messages at Read cPanel Error Log and find website errors.

Always note on relevant reports:

• Date and time
• affected file or URL
• exact wording
• if applicable, specified rule or cause

5. Check file permissions #

Incorrect file permissions are among the potential causes of a 403 error.

Open:

Files → File Manager

Navigate to the document root of the affected domain and check the permissions of the affected files and directories.

For typical websites, the following values can often be found:

Files:      644
Directories: 755

However, these are not values you should blindly apply to every file and directory.

You can find our detailed guide at How to correctly set file permissions 644 and 755 in cPanel.

Attention: Do not use as a general rule 777, to „resolve“ a 403 error. Extremely broad write permissions are not a clean fix and can pose a security risk.

Why incorrect permissions can cause a 403 #

The web server requires sufficient permissions to access the directories and files required for a request.

If these permissions are set too restrictively or inappropriately, access can be denied.

For example, the problem can occur after:

• of a manual file transfer
• of a migration
• unpacking an archive
• a manual change of permissions

occur.

6. Check the document root of the domain #

Check if the domain points to the directory where the actual website is located.

To do this, open:

Domains → Domains

Check the document root used for the domain.

We explain how domains and document roots are connected at Add and manage a domain in cPanel.

Incorrect document root can cause misleading errors #

Assuming your website is at:

/public_html/meinewebsite/

However, the domain points to a different directory.

Then the web server may process different content or a different directory than expected.

Therefore, always check first whether you are actually editing the files of the affected domain.

7. Check index file #

If a domain points to a directory where no suitable start file exists, a 403 error may appear instead of a directory listing, depending on the server configuration.

Typical start files are, for example:

index.php
index.html

Check in the file manager whether a matching start file is present in the document root of the website.

403 for a directory without an index file #

A typical case looks like this, simplified:

/public_html/downloads/
    datei-a.pdf
    datei-b.pdf
    datei-c.pdf

If you then only:

https://example.ch/downloads

you call it, the server does not automatically have to display a list of existing files.

If directory listing is disabled and no index file is present, access to the directory view can be denied.

This does not necessarily mean that the individual files within the directory are also locked.

Do not enable directory listing unnecessarily #

Do not enable directory listing or directory indexes solely to fix a 403 error.

A public file list can disclose information that is not intended for visitors.

Check first whether the directory is supposed to be accessed directly at all.

8. Check .htaccess as a possible cause #

The file .htaccess can contain access rules, redirects, and other Apache directives.

A faulty or intentionally restrictive rule can cause a 403 error.

The file is often located in the document root of the website.

If it is not visible in the file manager, read first Show hidden files like .htaccess in cPanel.

.Do not delete .htaccess immediately #

Don't just delete the file.

She can important rules for:

• WordPress permalinks
• Redirects
• Access protection
• Safety features
• custom website configurations

contain.

We explain how to edit them in a controlled manner under .htaccess explained and safely edited.

.Test .htaccess safely #

If the error occurs immediately after a change to the .htaccess occurred, you can create a backup first.

After that, you should specifically undo the last change made.

This is much better than removing all the rules at once.

Example:

Website works
        ↓
.htaccess rule added
        ↓
403 occurs
        ↓
specifically check new rule

Typical access restrictions in .htaccess #

A .htaccess can contain rules that intentionally deny access to certain resources.

If such a rule exists, a 403 error may be precisely the intended result.

Do not remove safety rules until you have understood their purpose.

9. Check cPanel IP blocking #

cPanel provides at:

Security → IP blocking

a function that allows blocking access from specific IP addresses or ranges.

If only certain visitors are affected, you should check whether a corresponding block is in place there.

Remove IP block only if it is actually incorrect #

A blocked IP address may have been intentionally blocked.

Therefore, do not remove a ban solely because a user reports a 403 error.

Check first:

• which IP is affected
• why she was banned
• whether the block is still required

10. Check ModSecurity as a potential cause #

CURIAWEB provides in cPanel under Security → ModSecurity appropriate security features.

ModSecurity can inspect HTTP requests based on security rules. If a request is classified as problematic, it can be blocked.

This may manifest as a 403 error under certain circumstances.

Typical situations with ModSecurity #

For example, a problem may only occur during a very specific action:

Access website        → works
Open WordPress          → works
Edit post               → works
Submit specific form    → 403

Such a pattern points more toward a request-based security rule than toward incorrect permissions for the entire website.

Do not disable ModSecurity permanently #

If you suspect that a security rule is involved, you should not simply disable the protection permanently.

This would remove a safety feature without addressing the root cause.

Important: If a legitimate request is reproducibly blocked by a security rule, document the affected URL, action, and exact time. This allows the cause to be investigated much more specifically.

11. Consider Imunify360 #

CURIAWEB also uses Imunify360 as a security solution on the hosting system.

Imunify360 is not a part of cPanel itself, but an additional security platform integrated into the hosting environment.

Security mechanisms can detect suspicious or classified as malicious activities and react accordingly.

If access is blocked due to a security measure, you should not bypass it without knowing the trigger.

403 after many login attempts #

If access is suddenly blocked after numerous failed login attempts or unusual activity, a security mechanism may be involved.

Check in particular whether:

• only your IP is affected
• the website works via another connection
• the error occurred after an unusually high number of login attempts

In this case, document your public IP address and the time of the issue for a technical review.

12. Check password-protected directories #

cPanel offers under:

Files → Folder Privacy

the option to additionally protect directories with access control.

If a directory has been intentionally protected, corresponding access restrictions may occur.

We explain how this protection is set up and managed under Password protect folders in cPanel.

13. Narrowing down WordPress as the cause #

If only one WordPress website is affected, additional WordPress-specific components may be involved.

This includes, for example:

• Security plugins
• Firewall plugins
• individual .htaccess-Rules
• Plugin conflicts
• Theme Code
• custom access restrictions

403 only in WordPress admin area #

When the public website works, but for example:

https://example.ch/wp-admin

produced a 403 error, you should specifically check:

• WordPress security plugins
• .htaccess-Rules
• IP-based restrictions
• ModSecurity
• other security mechanisms

A general domain or DNS problem is less likely in this case, since the public website is generally reachable.

403 only when saving a WordPress post #

If you can use WordPress normally, but receive a 403 error when saving a specific piece of content, the error pattern is particularly important.

Check if the error:

• occurs with every post
• occurs only with a specific content
• occurs after inserting certain HTML or script content
• only occurs during a specific action

A reproducible 403 on a specific HTTP request can indicate a security rule.

403 with forms #

When a contact form is displayed, but submitting it fails with a 403, the normal page load is already working.

The diagnosis should therefore focus on the request upon submission.

Possible areas are:

• ModSecurity
• Security plugin
• individual access rule
• faulty application configuration

For such issues, record the exact time of the failed attempt if possible.

403 after installing a plugin #

If the error starts immediately after the installation or activation of a WordPress plugin, this chronological connection is an important clue.

In particular, security, firewall, and login plugins can alter access controls.

We explain how to systematically isolate plugin and theme issues at Identify and resolve WordPress plugin and theme conflicts.

403 after a migration #

If a website shows a 403 error immediately after a migration, you should check in particular:

• Document Root
• File permissions
• .htaccess
• Startup file
• inherited access restrictions
• WordPress security plugins

Rules that worked on the previous hosting environment do not necessarily have to fit the new environment unchanged.

403 after unzipping a ZIP file #

If you have manually uploaded and extracted a website as an archive, check first:

• whether the files are in the correct document root
• whether a index.php or rather index.html available
• whether file and directory permissions are plausible
• whether an included .htaccess contains access restrictions

We explain how ZIP files are processed in the file manager at Compress and extract ZIP files in cPanel.

403 only with a specific file #

If the website works and only a single file produces a 403 error, focus the diagnosis on this resource.

Check:

• File permissions
• parent directory permissions
• .htaccess-Rules
• Hotlink protection
• Safety rules

Consider hotlink protection #

cPanel provides at:

Security → Hotlink Protection

a function that can restrict the direct embedding of specific files from external websites.

For example, if images or downloads only fail to work when embedded externally, you should also check this setting.

403 only for images or downloads #

If HTML pages work, but images, PDFs, or other files produce a 403 error, check in particular:

• File permissions
• Directory permissions
• Hotlink protection
• .htaccess-Rules
• ModSecurity or other security rules

Do not change the entire website configuration if only a single file type is affected.

DNS does not usually cause a classic 403 #

If you are already receiving a 403 response from the web server, a web server has basically been reached.

A classic DNS outage manifests itself differently.

However, a domain can, after a DNS change, point to a other server show. Then the web server there can of course return a 403 error.

Therefore, in the case of recent DNS changes, check whether the domain is actually pointing to the desired hosting environment.

SSL is also not the same as 403 #

A certificate error and an HTTP 403 are different types of errors.

If your browser already receives an HTTP status code 403, the HTTPS connection has fundamentally been established far enough to receive a web server response.

Therefore, do not change SSL certificates on suspicion if the actual message is 403.

Distinguish between 403 and 404 #

A 404 basically means that a requested resource was not found.

A 403, on the other hand, means that access is not allowed.

In WordPress, redirection and rewrite rules can additionally influence the visible behavior.

If you actually get a 404 error, our guide Fix WordPress 404 error the more suitable starting point.

Distinguish between 403 and 500 #

A 500 Internal Server Error indicates a server-side processing error.

A 403, on the other hand, denies access.

Therefore, if your website displays a 500 error, you should not take the same measures as you would for a 403.

You can find the appropriate instructions at Fixing a 500 Internal Server Error.

Differentiate between 403 and Resource Limit Is Reached #

A CloudLinux resource limit is also a different class of error.

When CloudLinux reaches a resource limit, you should analyze the resource usage rather than change file permissions.

See on this Resource Limit Is Reached: Identify and Fix CloudLinux Limits.

403 after editing own .htaccess #

If the error occurred immediately after a manual change, start diagnosing right there.

Example:

10:15 → .htaccess changed
10:16 → Website returns 403

This relationship is much more meaningful than a random change to PHP, DNS, or WordPress.

First, restore the last working state of the rule in question.

403 after changing file permissions #

The same principle applies to permissions.

If you changed permissions immediately before the error, check that change first.

Do not apply blanket permission changes to the entire account.

403 after activating a security feature #

If, for example, an access restriction, a security plugin, or another protective function was activated immediately beforehand, this change should be checked first.

That does not mean that the safety feature should be removed altogether.

Check instead whether it is configured correctly.

Always retest after making changes #

After each targeted change, you should test the exact same URL or action again.

Example:

reproduce 403
        ↓
change a possible cause
        ↓
test same URL again
        ↓
document result

This is how you can determine whether your change was actually relevant.

Consider browser cache in tests #

When troubleshooting, you should use a private browser window or a different browser after making changes, if necessary.

This reduces the risk that locally stored content will distort your assessment.

However, this does not lift server-side access restrictions.

Do not permanently disable any safety features #

A 403 error is often precisely the result of a security decision.

The wrong reaction would therefore be:

403 erscheint
        ↓
alle Sicherheitsfunktionen deaktivieren
        ↓
Website funktioniert
        ↓
Schutz bleibt ausgeschaltet

Damit wäre zwar möglicherweise das Symptom beseitigt, aber gleichzeitig eine Schutzfunktion entfernt.

The better approach is:

403 erscheint
        ↓
Auslöser identifizieren
        ↓
legitime oder unerwünschte Anfrage unterscheiden
        ↓
gezielt korrigieren

Keine Dateiberechtigungen 777 als Standardlösung #

Die Berechtigung 777 wird in älteren Internetanleitungen häufig als schnelle Lösung für Berechtigungsprobleme vorgeschlagen.

Das ist keine sinnvolle Standardmaßnahme.

Verwende nur die Berechtigungen, die für die betreffende Anwendung und Serverumgebung erforderlich sind.

403 systematisch diagnostizieren #

1. Notiere die genaue betroffene URL.
2. Prüfe, ob die ganze Website oder nur eine Ressource betroffen ist.
3. Teste die URL in einem privaten Browserfenster.
4. Prüfe bei Verdacht auf IP-Sperre eine zweite Internetverbindung.
5. Check Measured values → Errors.
6. Prüfe den Document Root der Domain.
7. Kontrolliere die betroffenen Datei- und Verzeichnisberechtigungen.
8. Prüfe, ob eine geeignete Indexdatei vorhanden ist.
9. Untersuche relevante .htaccess-Rules.
10. Prüfe gegebenenfalls die cPanel-IP-Blockierung.
11. Berücksichtige ModSecurity und andere Sicherheitsmechanismen.
12. Prüfe bei WordPress Sicherheitsplugins und kürzlich vorgenommene Änderungen.
13. Always change only one possible cause at a time.
14. Teste anschließend exakt dieselbe URL beziehungsweise Aktion erneut.

Was du bei einem 403 nicht tun solltest #

Avoid in particular:

• alle Dateien pauschal auf 777 put
• .htaccess delete without backup
• ModSecurity dauerhaft abschalten
• Sicherheitsplugins wahllos entfernen
• IP-Sperren ohne Prüfung löschen
• PHP-Version ohne Zusammenhang wechseln
• DNS-Einträge auf Verdacht verändern
• mehrere Einstellungen gleichzeitig ändern

Basic rule: Ein 403-Fehler bedeutet Zugriff verweigert. Konzentriere die Diagnose deshalb zuerst auf Berechtigungen, Zugriffskontrollen, Sicherheitsregeln und die konkret betroffene Ressource.

When should you contact CURIAWEB support? #

Wenn der 403-Fehler weiterhin besteht oder eine Sicherheitsregel als Ursache vermutet wird, dokumentiere das Problem möglichst genau.

Particularly helpful are:

• affected domain
• full affected URL
• Date and exact time
• visible error message
• ob die ganze Website oder nur eine bestimmte Aktion betroffen ist
• ob der Fehler über eine zweite Internetverbindung ebenfalls auftritt
• deine öffentliche IP-Adresse, falls nur dein Anschluss betroffen ist
• recent changes
• relevante Einträge aus dem Error Log

Wenn der Fehler nur beim Absenden eines Formulars oder bei einer bestimmten Aktion auftritt, beschreibe zusätzlich genau, welche Schritte den Fehler reproduzieren.

Summary #

A 403 Forbidden bedeutet, dass der Webserver die angeforderte Ressource grundsätzlich erreicht, den Zugriff darauf aber verweigert.

Zu den häufigsten Bereichen, die du überprüfen solltest, gehören Dateiberechtigungen, Document Root, Indexdateien, .htaccess, IP-Sperren, ModSecurity und andere Sicherheitsmechanismen.

Wenn nur deine eigene Internetverbindung betroffen ist, solltest du eine IP-bezogene Sperre berücksichtigen. Wenn dagegen nur eine bestimmte Aktion wie das Absenden eines Formulars einen 403 erzeugt, kann eine anfragebezogene Sicherheitsregel beteiligt sein.

Bei WordPress können zusätzlich Sicherheitsplugins, individuelle Zugriffsbeschränkungen und Plugin-Konflikte relevant sein.

Do not set file permissions globally to 777 und deaktiviere Sicherheitsfunktionen nicht dauerhaft, nur damit der Fehler verschwindet.

Vergleiche den Zeitpunkt des Fehlers mit dem Error Log und mit kürzlich vorgenommenen Änderungen. Ändere anschließend immer nur eine mögliche Ursache und teste erneut.

The most important rule is: Erst feststellen, wer oder was tatsächlich vom Zugriff ausgeschlossen wird – und danach die konkrete Zugriffsbeschränkung gezielt untersuchen.