Here is a fact that surprises a lot of people: HTTP Basic Authentication sends your password in every single request. Not just when you log in. Every request. And the password is not encrypted. It is base64-encoded, which is a fancy way of saying it is slightly obfuscated plaintext.
This sounds terrible. And it would be, if not for one thing: HTTPS. Let's talk about how Basic Auth actually works, why it is safe over HTTPS, and what goes wrong when you use it without HTTPS.
How Basic Auth Works
When a browser requests a resource protected by Basic Auth, the server responds with a 401 Unauthorized status and a WWW-Authenticate header:
HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="Restricted Area"
The browser shows a login dialog. The user enters a username and password. The browser takes the credentials, concatenates them as "username:password", and base64-encodes the result. It then sends this in the Authorization header on the next request:
GET /private/ HTTP/1.1 Authorization: Basic YWRtaW46cGFzc3dvcmQ=
That base64 string decodes to "admin:password". The server decodes it, checks the credentials against the .htpasswd file, and either serves the content (200 OK) or denies access (401 Unauthorized).
The browser caches the credentials and sends them with every subsequent request to the same realm on the same server. This is why you do not see the login dialog on every page: the browser remembers your credentials for the session.
Why Base64 Is Not Encryption
This is the part that confuses people. Base64 looks like encrypted text. It is not. Base64 is an encoding, which means it is a reversible transformation that anyone can undo. There is no key, no secret, no computational work. You paste a base64 string into any decoder and you get the original text back instantly.
This is by design. Base64 was created to allow binary data to be transmitted over text-only protocols. It has nothing to do with security. The "Basic" in Basic Auth refers to the fact that the credentials are sent in a basic (readable) format, not in any encrypted form.
If someone intercepts an HTTP request with Basic Auth credentials, they can decode the base64 and read the password in less than a second. There is no cracking involved. It is just decoding.
Why HTTPS Makes It Safe
Here is where HTTPS comes in. When you use HTTPS, the entire HTTP request is encrypted before it leaves the client. This includes the headers, the body, and the Authorization header with the base64-encoded credentials.
The encryption is done by TLS, which uses strong ciphers (typically AES-256-GCM, the same algorithm we cover in our AES-256-GCM explained post). An attacker intercepting the traffic sees only encrypted data. They cannot read the Authorization header, they cannot decode the base64, and they cannot get the password.
From the perspective of someone on the network, the request is just encrypted bytes. The credentials are as safe as the TLS connection, which is to say, very safe. TLS has been battle-tested for decades and is the same protocol that protects your banking sessions, your email, and your online shopping.
So the answer to "Is Basic Auth secure?" is: it depends on the transport. Over HTTPS, Basic Auth is secure. Over HTTP, it is catastrophically insecure. The difference is not in the authentication mechanism itself, but in whether the transport layer protects the credentials in transit.
What Goes Wrong Without HTTPS
Let's be concrete about what happens if you use Basic Auth over plain HTTP.
**Network interception:** Anyone on the same network (coffee shop WiFi, corporate network, ISP) can see the Authorization header in cleartext. Tools like Wireshark make this trivial. They decode the base64 and have your password in seconds.
**Proxy and CDN logging:** If your traffic passes through a proxy, CDN, or load balancer that terminates HTTP (not HTTPS), the Authorization header may be logged. Many proxies log headers by default for debugging. Your password ends up in a log file that may be stored indefinitely and accessible to many people.
**Browser history and caching:** Some browsers cache the Authorization header in memory, which is fine. But if the browser also caches the page content, and the page is served over HTTP, the cached content may include the authenticated URL in a way that leaks credentials.
**Credential leakage to HTTP:** If your site is available over both HTTP and HTTPS, and a user visits the HTTP version, the browser may send the cached Basic Auth credentials over the unencrypted connection. This is a real risk with mixed-protocol setups.
Best Practices for Basic Auth
If you are using Basic Auth, follow these rules:
**Always use HTTPS.** This is non-negotiable. If your site does not have HTTPS, do not use Basic Auth. Set up HTTPS first (Let's Encrypt is free and takes 10 minutes), then add Basic Auth.
**Use strong passwords.** Basic Auth does not protect against brute-force attacks on its own. If an attacker can guess passwords, they can get in. Use strong, unique passwords for .htpasswd entries. Our htpasswd generator can help you create them.
**Use bcrypt hashes.** If someone does steal your .htpasswd file (through a server misconfiguration or a vulnerability), bcrypt hashes are much harder to crack than APR1 or SHA. See our htpasswd bcrypt vs APR1 comparison.
**Do not log the Authorization header.** Check your server, proxy, and CDN configurations to make sure the Authorization header is not being logged. This is a common misconfiguration that leaks passwords into log files.
**Protect the .htpasswd file.** Make sure the .htpasswd file is not accessible via HTTP. Put it outside the document root or block access to it. See our Apache .htaccess guide for details.
**Consider rate limiting.** Basic Auth does not have built-in rate limiting. An attacker can try unlimited password guesses. Use a module like mod_security (Apache) or limit_req (nginx) to rate-limit authentication attempts.
When to Use Basic Auth vs Alternatives
Basic Auth is great for: - Protecting a staging or development site from casual access - Securing an admin panel or internal tool - Authenticating API clients (with API keys or tokens, not human passwords) - Quick and simple protection where building a full login system is overkill
Basic Auth is not great for: - Public-facing applications with many users - Applications that need proper logout (Basic Auth cannot do this reliably) - Applications that need CSRF protection - Applications where credentials should not be sent on every request
For public-facing applications, a session-based authentication system with login forms, CSRF tokens, and proper logout is more appropriate. Basic Auth is a tool for simple, server-level protection, not a replacement for application-level authentication.
The Bottom Line
Basic Auth over HTTPS is secure. Basic Auth over HTTP is not. The difference is the transport layer, not the authentication mechanism. As long as you use HTTPS, use strong passwords, use bcrypt hashes, and protect your .htpasswd file, Basic Auth is a perfectly valid way to protect directories and endpoints.
If you need to generate .htpasswd entries, use our htpasswd generator. And if you need help with the setup, read our Apache .htaccess guide.
