Password Protecting a Directory in cPanel: Setup & Fixes

You've got a staging site, an internal tool, or a folder full of files you don't want strangers stumbling onto. cPanel's "Directory Privacy" feature can lock it behind a username and password in about two minutes — but it also breaks in a few predictable ways once WordPress, caching, or a CDN gets involved. Here's how to set it up properly and fix it when the login prompt won't behave.

What Directory Privacy Actually Does

This isn't the same as your cPanel or WordPress login. It's HTTP Basic Authentication — the plain browser popup that asks for a username and password before it'll show you anything in that folder at all, before your site or app even loads. It's enforced by Apache (or LiteSpeed) at the web server level, using two files it creates for you:

• .htaccess — added to the protected folder, telling the server "require auth here"
• .htpasswd — a file storing the username and an encrypted password hash, usually sitting one level above public_html so it isn't web-accessible

People use it for staging copies of a live site, client preview folders, internal admin scripts, or a /wp-content/uploads/private/ style folder that shouldn't be public but also shouldn't be deleted.

Setting It Up in cPanel

1. Log in to cPanel and open Directory Privacy under the Files section (some themes list it as "Directory Privacy" or just "Privacy").
2. Navigate to the folder you want to protect — for example public_html/staging.
3. Click the folder name, tick "Password protect this directory", give it a label, and save.
4. Scroll down and create a user: pick a username and a strong password, then click Save.

That's it on the cPanel side. Visit the folder in a private/incognito window and you should get a browser popup asking for credentials before anything loads.

Symptom: The Popup Never Appears, or It Loops Forever

Two failure patterns show up constantly in support tickets:

• No prompt at all — the folder loads normally, protection seems to do nothing.
• The prompt keeps reappearing — you enter the correct password, hit enter, and get asked again. Sometimes it just throws a 401 Unauthorized page instead of retrying.

Cause 1: Caching or a CDN Is Serving an Old Copy

If Cloudflare, a browser cache plugin, or your host's page cache already has a cached copy of that URL from before you enabled protection, visitors get served the cached page and never hit Apache's auth check at all. This is the most common reason "nothing happens" after setup.

Fix: purge the CDN cache for that path, and if you're using Cloudflare, add a Page Rule (or Cache Rule) for that folder set to Bypass Cache. Password-protected folders generally shouldn't be cached anywhere in the chain.

Cause 2: .htaccess Conflicts With Existing Rules

If the folder already has an .htaccess file — a WordPress install's rewrite rules, for instance — cPanel appends the auth block to it rather than replacing it. Order matters here. If another rule higher up redirects or rewrites the request before Apache evaluates the auth directive, you can get an infinite prompt or the auth block gets skipped entirely. Open the file via File Manager and check that the block looks like this, ideally near the top:

AuthType Basic
AuthName "Restricted Area"
AuthUserFile /home/yourcpaneluser/.htpasswds/public_html/staging/passwd
Require valid-user

If you see Order deny,allow or Order allow,deny lines mixed in from an older Apache 2.2-style config, they can interact oddly with Require valid-user on Apache 2.4. Remove the legacy Order/Allow/Deny lines unless you specifically need IP-based rules alongside the password prompt.

Cause 3: Wrong Path or Bad Permissions on .htpasswd

cPanel usually stores the password file outside public_html, under a path like /home/username/.htpasswds/public_html/staging/passwd. If that path is wrong in the AuthUserFile line — common after a site migration where the cPanel username changed — Apache can't read it, and depending on your server's config that either fails open (no protection) or fails closed (permanent 500/403).

Fix: confirm the file exists at the exact path referenced in .htaccess, and check permissions:

chmod 644 /home/username/.htpasswds/public_html/staging/passwd
chmod 750 /home/username/.htpasswds

If you migrated this site from another server or another cPanel account, regenerate the protection from scratch in Directory Privacy rather than copying the old .htaccess/.htpasswd pair over — the absolute paths won't match the new account.

Cause 4: You Protected the Whole Site, Not Just a Folder

If you password-protected public_html itself instead of a subfolder, every request — including AJAX calls, cron pings, image loads, and API calls — now demands Basic Auth credentials. A WordPress site behind full-site protection will show broken images, failed AJAX requests in the console, and a WP‑Cron that silently stops firing, because none of those background requests carry the browser's saved credentials.

Fix: only protect the specific folder that needs it (a staging copy, an admin script, an internal tool). If you genuinely need to gate an entire WordPress site during development, use a maintenance-mode plugin or an IP allowlist in .htaccess instead of Basic Auth — it won't fight with AJAX and cron the way directory privacy does.

Adding or Removing Users Later

Go back into Directory Privacy, select the folder, and you can add more username/password pairs or delete existing ones from the same screen. There's no limit on how many users share access to one protected folder — useful when a few teammates or a client need their own login rather than sharing one password.

Quick Checklist Before You Walk Away

• Bypass caching (CDN and any server-side page cache) for any path you protect this way.
• Protect the narrowest folder that solves the problem — not the site root.
• After a migration, regenerate protection through cPanel rather than reusing old .htaccess/.htpasswd files with stale paths.
• Test in an incognito window after every change — browsers cache Basic Auth credentials aggressively, which can hide a broken config from you.
• Document the credentials somewhere your team can find them; Basic Auth has no "forgot password" flow — losing the password means resetting it in cPanel.

Prevention

Directory Privacy is a good, lightweight tool for exactly one job: keeping casual visitors and search engines out of a folder that isn't ready for the public. It's not a substitute for real application-level security, and it doesn't play well with anything that needs to hit that folder without a human typing a password — cron jobs, webhooks, API integrations, and CDNs included. Scope it narrowly and it'll cause you almost no trouble.