HTTP Basic authentication, defined in RFC 7617, joins a username and password with a colon and Base64-encodes the result:
Authorization: Basic YXBpX3VzZXI6czNjcjN0That Base64 is not protection. Anyone who sees the header decodes it instantly — the Base64 decoder does it in one paste. The encoding exists to carry arbitrary bytes safely in a header, nothing more.
When Basic is acceptable
Over TLS, with a high-entropy random key as the username and an empty password. Many payment and infrastructure APIs work exactly this way, and it is a reasonable design: the credential is unguessable, and TLS protects it in transit.
When it is not
- Over plain HTTP. The credential is readable by anyone on the path. There is no mitigation.
- With a human-chosen password. The password is transmitted on every single request, so every request is an opportunity to leak it.
- In a URL.
https://user:pass@example.computs the credential in browser history, logs andRefererheaders. Browsers have been removing support for good reason.
The empty password
Where an API uses Basic with an API key, the convention is the key as username with an empty password. The trailing colon is required and easy to lose:
# Correct — note the trailing colon
curl -u sk_live_abc123: https://api.stripe.com/v1/charges
# Wrong — curl prompts for a password interactively
curl -u sk_live_abc123 https://api.stripe.com/v1/chargessk_live_abc123: and sk_live_abc123 encode to different Base64 values, and the second one fails authentication with an error that does not mention the colon.
Keep it out of your shell history
A key on the command line is written to ~/.bash_history or ~/.zsh_history in plaintext. Read it from the environment instead:
export API_KEY="sk_live_..."
curl -u "$API_KEY:" https://api.example.com/v1/resourceBetter still, use curl --netrc with a .netrc file that is mode 600 and gitignored.
Frequently asked questions
Is Basic auth secure?
The scheme is as secure as the credential and the transport. Over TLS with a 256-bit random key it is fine. Over HTTP, or with a weak password, it is not. Base64 contributes nothing either way.
Why does my Basic auth fail with a special character in the password?
Base64 handles any bytes, so the encoding is not the problem. The usual cause is character encoding — a non-ASCII character encoded as Latin-1 by one side and UTF-8 by the other produces different bytes. RFC 7617 defines a charset parameter for this; support is inconsistent.
Should I use Basic or Bearer?
Bearer for OAuth tokens and JWTs. Basic where the API documents it, typically for a static key. A custom X-API-Key header is clearer than either for a static key, because it implies neither refresh semantics nor a password.
Can I use Basic auth in a browser fetch?
You can, but you are then shipping a credential to every user who loads the page. If the API is called from a browser, the credential must be one that is safe to make public — otherwise proxy the call through your own backend.