Directory password protection puts a browser prompt in front of a folder. It is the crudest access control available and, for a few specific jobs, the right one, because it works before your application runs.
The mechanics in the panel are covered separately in How to Password Protect Directories in cPanel. This article is about when to reach for it and where it lets you down.
What it does that an application login cannot
The distinction that decides whether it is the right tool.
An application login runs inside the application. The request reaches PHP, the application loads, and then it decides you are not allowed in. Anything that goes wrong before that point; a vulnerability in the login page itself, a file served directly, an error page leaking a path, happens anyway.
Directory protection refuses the request at the web server. Nothing behind it executes, including the vulnerability you have not patched yet.
That is why it is a genuinely useful stopgap on a site you know is exposed, in the hours before you can fix the real problem.
Where it earns its place
A staging copy. One password keeps it away from visitors and from crawlers at the same time, and unlike a noindex tag, it also stops anyone who finds the address from reading the site. How to Set Up a Staging Environment on a VPS goes into the rest of that setup.
A site not launched yet, where a holding page is not enough.
A directory of files shared with a few people, where building a login system is disproportionate.
An admin path under attack, as a temporary layer while you deal with the cause.
Where it backfires
Four cases, and the first two are common enough to expect.
On a WordPress admin directory, it breaks the site's own background requests. The editor, autosave, and anything using the site's internal endpoints, because those requests do not carry the browser prompt's credentials.
On anything an integration reaches. A payment gateway calling back, a monitoring service, a mobile app. Each gets a prompt it cannot answer, and each fails silently from your side.
As a substitute for real access control. One shared password given to twelve people cannot be revoked for one of them.
On anything indexed. Protecting a directory that search engines already know about removes those pages rather than hiding them, and the recovery is slower than the protection was useful.
It is only as private as the connection
The credentials are sent with every request, encoded rather than encrypted.
Over HTTPS that is fine. Over plain HTTP it is a password sent in the clear on every page load, which is worse than most people assume when they use this to protect something sensitive.
So: never enable it on a site that is not already forcing HTTPS. How to Force HTTPS and Redirect HTTP to HTTPS sets out doing that first.
One user per person, and remove them
The feature supports multiple users, and using it properly is the difference between access control and a shared secret.
Give each person their own username so removing one person is one deletion. A shared login means changing it for everybody, which means it does not get done when somebody leaves.
Review the list when the reason for the protection ends. A staging site that launched, a project that finished. Protection nobody remembers is protection nobody maintains.
What it does not protect
Worth being explicit, because it is often over-trusted.
It protects that directory as served by the web server. It does not protect the same files reached by another path, it does not protect the database, and it does not protect anything the application itself exposes elsewhere.
A file that must not be public should not be under public_html at all. Placement is the control; a password prompt is a second line. For that, see Understanding File Permissions and Ownership.
Better tools for adjacent jobs
Keeping a page out of search results; a noindex header, which does not inconvenience visitors.
Restricting to your office. An IP rule, which asks nobody for a password. There is more in IP Blocker and Leech Protection in cPanel.
Real per-user access, accounts in the application, with roles.
Protecting paid content: served through the application after a check, never as a directory anyone can be given the password to.
Test it logged out
After enabling it, open the directory in a private window and confirm the prompt appears.
Then try a file inside it directly, and any path that might reach the same files another way. The prompt on the folder listing tells you less than a direct request to something inside it, and the direct request is what somebody else will try.
Where a password is not enough because it can be phished, the credential can be moved into the connection itself. How to Use Client Certificates to Restrict Access goes into the trade.
Check what it is actually protecting
Directory protection applies to a path, and the thing you meant to protect is frequently reachable by another one.
curl -sI https://example.com/private/ | head -1 curl -sI https://example.com/private/file.pdf | head -1 curl -sI https://example.com/private/sub/ | head -1 curl -sI 'https://example.com/index.php?file=private/file.pdf' | head -1
Each of those must ask for credentials. A protected directory whose files are also served by an application through a different address is not protected, since the application reads the file itself and the rule never applies.
The same holds for a search index, a sitemap or a cached copy that lists the contents. The rule stops direct access and does nothing about anything that already recorded what is inside.
Failed attempts are worth watching
Protection that nobody watches tells you nothing about whether it is being tested.
grep -c ' 401 ' ~/logs/example.com
awk '$9 == 401 {print $1}' ~/logs/example.com | sort | uniq -c | sort -rn | head
A handful of failures is somebody mistyping. Hundreds from one address is an attempt to guess, and the protection has no rate limit of its own, so it will accept attempts indefinitely.
Where that appears, the answer is to restrict by address as well, or to move the resource behind something that can lock an account. The password prompt is a door, not a guard. cPHulk brute force protection deals with the server level control.
Remember it exists
The commonest problem with this feature is not security. It is that a directory gets protected during a migration or a redesign and nobody removes it afterwards.
find ~/public_html -name '.htpasswd' 2>/dev/null grep -rl 'AuthType' ~/public_html --include='.htaccess' 2>/dev/null
Run that occasionally. What turns up is usually a staging directory that has since become the live site, or a section that quietly stopped being visited because visitors met a password box and left.
The second is the expensive version, because nothing reports it. The pages return a valid response, search engines drop them, and the traffic decline is attributed to something else entirely.