With the cPanel feature Folder data privacy you can protect access to a directory of your website with a username and password.
Visitors will then no longer be able to access content within this protected area without logging in. Instead, the browser will first request the stored login credentials.
This is suitable, for example, for development areas, internal files, test directories, or websites that should not yet be publicly accessible while they are being worked on.
In this guide, we will show you step by step how to password-protect a folder in CURIAWEB, create users for the protected area, and remove the protection later.
Important: Directory protection is not the same as a WordPress user account or password protection for an individual WordPress page. Access control takes place at the web server level for the protected directory.
What does password protection do? #
When you protect a directory, the web server requires authentication when accessing protected content.
For example, a visitor accesses a protected area:
Before the content is displayed, a browser login prompt appears.
The protected area can only be accessed with a valid username and password.
What content is protected? #
The protection applies to the selected directory and generally also affects its contents and any underlying directories, unless a differing configuration applies.
For example, if you directory:
public_html/intern
protects, this affects content such as:
public_html/intern/index.html
public_html/intern/dokumente/
public_html/intern/downloads/datei.pdf
You should therefore check carefully which directory you select.
Attention: If you accidentally protect the document root of your entire website, visitors may be required to authenticate for the complete site.
1. Log in to cPanel #
Log in to your CURIAWEB cPanel.
Then open in the area Files the function:
Folder data privacy
cPanel will then show you the directory structure of your hosting account.
2. Select desired directory #
Navigate to the folder you want to protect.
On a website, for example, this can be located within:
public_html
to be situated.
A possible test area would be, for example:
public_html/test
Check the path carefully before activating protection.
Check directory structure in the file manager beforehand #
If you are not sure which directory belongs to a specific website or area, you can check the structure beforehand in the cPanel File Manager.
We explain how to use it at Use cPanel File Manager.
Practical Tip: Especially when dealing with multiple domains, you should not decide based on the folder name alone. Make sure that you are actually protecting the desired document root or subdirectory.
3. Enable directory protection #
After selecting the desired directory, enable the option to Password protection of this directory.
Depending on the language setting, the exact name of the option may vary slightly.
Then, assign a name for the protected area.
This name is used to identify the protected directory and may be displayed during the authentication prompt.
For example:
Internal area
or:
Test website
Then save the setting.
Important: Activating directory protection alone is not enough. You also need at least one user who can log in to the protected area.
4. Create users for the protected area #
In the user management section, you can now create a user who should be granted access to the protected directory.
Assign a username.
For example:
project access
Do not use an easily guessable username if the area contains sensitive content.
5. Set a secure password #
Then assign a strong password.
A good password should be sufficiently long and must not consist of simple terms, company names, or well-known personal information.
Do not use passwords such as:
123456
password
admin123
or the name of the domain.
If cPanel offers a password generator or a password strength indicator, you can use these features.
Safety: Do not use the same password for directory protection as you do for cPanel, your email account, WordPress, or other important logins.
6. Save users #
Save the new user.
This means that the username and password for accessing the protected directory are now available.
If multiple people need to receive different access credentials, you can create additional users for the protected area.
7. Test password protection #
Then open the protected area in your browser.
For example, if you:
public_html/test
you protected and this folder via the domain at:
is reachable, open this address.
The browser should now require authentication.
8. Log in with username and password #
Enter the previously created username and the corresponding password.
After successful login, the protected content should be displayed.
Then, also test whether access with incorrect credentials is indeed denied.
Practical Tip: Test the protection additionally in a private browser window. Your regular browser may cache an already successful authentication for the ongoing session.
Why isn't the password prompt appearing again? #
Browsers can cache HTTP authentication credentials for a certain period of time or for the duration of a browser session.
Once you have successfully logged in, the prompt therefore may not appear every time you reload the page.
This does not automatically mean that the directory protection has been disabled.
For an independent test, you can, for example, use a private browser window or a different browser.
Create multiple users for a folder #
You can create multiple users for a protected area.
This makes more sense than giving several people the same username and password.
For example, if three people need access, separate accounts can be set up.
This allows you to remove an individual person's access later without having to change the password for all other users.
Remove user #
If a user should no longer be granted access, open again:
Files → Folder Privacy
Select the protected directory and open the user management.
Remove the unneeded user there.
Then, if necessary, test whether its access actually no longer works.
Change a user's password #
If a password is no longer to be used or may have become known, you should change it or reconfigure the user in question.
Use only the new password from then on.
Important: If you suspect that access credentials have been compromised without authorization, change them promptly. Password protection is only as effective as the credentials used.
Remove password protection from a folder again #
If the protected area should be publicly accessible again, open:
Files → Folder Privacy
Select the relevant directory and disable password protection.
Then save the change.
Open the relevant URL in a private browser window afterwards and check whether the content is accessible again without authentication.
Check user accounts after protection removal #
If the password protection is permanently no longer needed, you should also check whether created users for this area are still required.
You should not make unnecessary credentials persistent.
Password protection for an entire website #
In principle, you can also protect the document root of a website.
For example, if the main website is located at:
public_html
is located and this directory is protected, the authentication can affect the entire website located within it.
This can be useful, for example, during a development phase.
Attention: Do not accidentally protect all websites in a hosting account by selecting a parent directory that is too high up.
Password protection for a development website #
An as-yet unpublished development website can be protected from normal visitors using directory protection.
This is practical, for example, when a new website is being built under a subdomain or in a subdirectory.
However, this protection does not automatically prevent any form of access to or sharing of already publicly available information outside of this directory.
Password protection and search engines #
A properly server-side protected area cannot be accessed by a regular search engine crawler without valid credentials like a freely accessible website.
This is often more sensible for development or internal areas than merely using a note like „Please do not index“ on an otherwise publicly accessible page.
Briefly explained: Password protection controls access. A
noindex-instruction, on the other hand, controls the desired search engine indexing. These are different mechanisms.
Password protection is not a substitute for an application's user management #
If you need different roles, user rights, or personal accounts within an application, cPanel directory protection is usually not the right solution.
For example, a WordPress membership area often requires user management within WordPress.
In contrast, cPanel directory protection is an upstream access restriction for an entire web area.
Password protection is not a file encryption system #
Directory protection prevents normal access via the web server without valid authentication.
However, this does not automatically encrypt the files themselves.
Anyone who can access the hosting file system via another appropriately authorized access method is working on a different access level.
Important: Password protection and encryption are two different security measures.
Use HTTPS for protected areas #
A password-protected web area should be accessed via HTTPS.
Therefore, use an address like:
and not unencrypted:
http://example.com/intern/
HTTPS protects the transmission between browser and web server.
After activation, a 500 Internal Server Error appears #
Depending on the server configuration, cPanel directory protection can work with configuration files or authentication rules.
If immediately after a change a 500 Internal Server Error appears, you should not add further rules on suspicion.
First, check whether the error is actually directly related to the activation of the directory protection.
We cover systematic troubleshooting under Fixing a 500 Internal Server Error.
403 Forbidden instead of password prompt #
If instead of the expected login a 403 Forbidden appears, the cause may lie, for example, in access rules, permissions, or another configuration of the directory.
We are treating the diagnosis under Fix 403 Forbidden.
.htaccess and directory protection #
Depending on the web server configuration, authentication rules can .htaccess or related mechanisms are implemented.
If you simultaneously manually on .htaccess you should therefore be careful when working.
Do not remove unknown authentication rules just because you did not enter them yourself.
We explain safe processing at .htaccess explained and safely edited.
Do not delete hidden authentication files #
For password protection, configuration or access data can be stored in files that are not intended for manual editing.
If you notice new unknown files or configuration entries after activating protection, you should not delete them on suspicion.
Password protection no longer works after .htaccess change #
If directory protection was working previously and immediately after a manual .htaccess-If the change no longer works, you should check the changes you made most recently.
If necessary, restore the previously backed up configuration.
Password prompt keeps appearing #
If the browser repeatedly asks for your username and password even though you have entered the details, check first:
- whether username and password were entered correctly
- whether the user was created for the correct protected area
- whether capitalization is correct
- whether the password has been changed in the meantime
- whether multiple nested areas are protected differently
Test the access with a newly created user if necessary.
Password prompt does not appear at all #
If no authentication prompt appears, first check whether password protection for the correct directory was actually activated and saved.
Also check the URL and the associated document root.
Then test in a private browser window so that an existing session does not distort the result.
Protected file is accessible anyway #
If a specific file is accessible despite protection being enabled, first check whether it is actually located within the protected directory.
A file in:
public_html/downloads/datei.pdf
is not protected, for example, by the fact that only:
public_html/intern
has been password-protected.
The actual storage location is crucial.
Multiple nested protected areas #
It is possible that protected directories are located within other protected directories.
This can make the access configuration more complex.
If there is no specific reason for it, you should avoid unnecessarily complex nesting.
Do not store passwords in URLs or filenames #
Do not store access credentials in publicly visible filenames or URLs.
A directory like:
/intern-passwort-12345/
is not a sensible security measure.
Protection should be achieved through authentication, not by guessing a supposedly unknown directory name.
Share access data securely #
If you want to grant another person access to a protected area, you should transmit the username and password via a suitable secure communication channel.
Separate user accounts are useful when there are multiple people.
If a person no longer needs access, you can then specifically remove their access.
Remove directory protection before publication #
If you have protected a development website, you should check whether the protection has actually been removed before publishing.
Then test the website without an existing browser login.
A private browser window is particularly well-suited for this.
Practical Tip: Test a new website before go-live from the perspective of a regular visitor: open a private browser window, visit the domain, and check that no unexpected password prompt appears anymore.
Recommended procedure for setting up password protection #
- Log in to cPanel.
- Open Files → Folder Privacy.
- Select the desired directory.
- Enable password protection.
- Assign a name for the protected area.
- Save the setting.
- Create at least one user.
- Generate a strong, unique password.
- Open the protected area in the browser.
- Test valid and invalid credentials.
Recommended procedure for removing the protection #
- Open Files → Folder Privacy.
- Select the protected directory.
- Disable password protection.
- Save the change.
- Check for no longer required users.
- Test the area in a private browser window.
Basic rule: Always protect only the directory that actually needs to be protected, and then test the access from the perspective of a non-logged-in visitor.
When should you contact support? #
If directory protection does not work as expected, you should first check whether the correct directory was selected and at least one valid user exists.
For further analysis, the following information is particularly helpful:
- affected domain
- protected directory
- URL of the protected area
- whether a password prompt appears
- whether valid access credentials are rejected
- whether an HTTP error such as 403 or 500 is displayed
- whether changes were previously made to
.htaccesshave been made
Do not transmit the password used. The password itself is not required for error analysis.
Summary #
With Files → Folder Privacy Can you protect individual directories or complete website areas with additional authentication in the CURIAWEB cPanel?.
First, select the correct directory and enable its password protection. Afterward, you will create at least one user with a secure password.
Test the protected area afterwards in a private browser window. This way you can check whether visitors without valid credentials actually do not get access.
When protection is no longer needed, disable it again and remove user accounts that are no longer required.
Please also note that cPanel directory protection is a server-side access control. It neither replaces a web application's user management nor encrypts the stored files.
