Password Protect a Directory in cPanel: Full Guide

A client preview build, a staging copy of a live site, an internal reports folder — sooner or later you need a directory that only certain people can open, without building a whole login system for it. cPanel has had a tool for exactly this for years, and if you're on a VPS without cPanel, the same trick works with two plain text files. Here's how to set it up properly, and how to fix it when it locks you out or breaks WordPress instead.

What Directory Privacy Actually Does

This isn't application-level authentication — it's HTTP Basic Auth, handled entirely by the web server before your PHP or static files ever load. When someone requests a URL inside the protected folder, the browser pops up a native username/password prompt. No page is served, no theme loads, nothing until the credentials check out. That makes it fast and dependable, but also limited: it protects the folder, not what happens after login, and it has no forgot-password flow or user roles.

Under the hood, cPanel writes two things: an AuthType Basic block in an .htaccess file inside the folder you're protecting, and a separate password file (usually under /home/username/.htpasswds/) that stores the username and a hashed password. Apache (or LiteSpeed, which honours the same directives) reads both on every request to that path.

Setting It Up in cPanel

1. Log into cPanel and open File Manager, or go straight to Directory Privacy under the Files section.
2. Navigate to the folder you want to lock — for example public_html/client-preview. If you don't see it listed, click into it from File Manager first, since Directory Privacy shows the current directory's subfolders.
3. Click the folder, then check Password protect this directory and give it a label (this is just a display name shown in the login prompt, not the folder name).
4. Save, then scroll down to Create User. Enter a username and a strong password, and click Save.
5. Repeat the Create User step for every additional person who needs access — Directory Privacy supports multiple accounts on the same folder.

That's the whole cPanel-side job. Test it in a private/incognito browser window (not the one you're logged into cPanel with) to make sure the prompt actually appears and your credentials work.

Doing It Manually With .htpasswd (No cPanel)

On an unmanaged VPS running plain Apache or Nginx, you'll set the same thing up by hand. For Apache:

htpasswd -c /etc/apache2/.htpasswds/site/passwd clientuser

Drop the -c flag for every user after the first one, or it'll overwrite the file instead of appending. Then add this to an .htaccess file inside the target directory (make sure AllowOverride AuthConfig or All is set for that path in your vhost, or the directives get silently ignored):

AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/apache2/.htpasswds/site/passwd
Require valid-user

Nginx doesn't read .htaccess at all, so the equivalent lives directly in the server block:

location /client-preview/ {
    auth_basic "Restricted Area";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

Generate that password file with htpasswd -c /etc/nginx/.htpasswd clientuser (install the apache2-utils or httpd-tools package if the htpasswd command isn't found), then reload Nginx with nginx -s reload.

Common Problems After Enabling It

If you do need to exclude a specific file from an otherwise protected folder — the admin-ajax case above is the most common — add this above the Require valid-user line:

<Files "admin-ajax.php">
    Require all granted
</Files>

Removing Directory Privacy

Go back to Directory Privacy in cPanel, select the folder, and simply uncheck Password protect this directory, then save. cPanel removes the auth block from .htaccess but usually leaves the password file behind, which is harmless — delete it manually from .htpasswds in File Manager if you want it fully gone.

Prevention: Getting It Right the First Time

• Protect a subdirectory, not your document root. Locking public_html itself takes your whole live site offline for anyone without the password — almost never what people actually want.
• Basic Auth isn't encryption. Credentials are base64-encoded, not hashed, in transit, so only ever use this over HTTPS. Never rely on it alone for anything holding real customer data.
• It won't stop crawlers from listing the URL. Search engines can't read protected content, but the URL path itself can still leak through referrers or sitemaps. Add a Disallow entry in robots.txt for extra-sensitive paths.
• Write the credentials down somewhere your team can find them. The single most common support ticket on this feature isn't a misconfiguration — it's someone forgetting the password to their own staging folder three weeks later.

Frequently Asked Questions

Does directory password protection slow down my site?

No. Basic Auth adds one extra header check per request handled directly by the web server — the overhead is negligible even on shared hosting.

Is this the same as my WordPress admin login?

No, it's a completely separate layer that runs before WordPress even loads. You can stack both — Basic Auth on a staging folder, then the normal wp-admin login on top — for two independent checks.

Can I protect just one file instead of a whole folder?

Yes. Use a <Files> block around the same AuthType/AuthUserFile/Require valid-user directives instead of applying them to the whole directory, targeting only the filename you need locked down.

Why does the password prompt keep reappearing even after I log in correctly?

Almost always a path mismatch between where cPanel (or your .htaccess) points for AuthUserFile and where the password file actually sits. Re-check the exact path, including case sensitivity on Linux.

Will this protect a subdomain the same way?

Yes — a subdomain is just another directory as far as Apache/Nginx is concerned, so Directory Privacy or a manual .htaccess works the same way against its document root.