I'm making a REST-API and it's straight forward to do BASIC auth login. Then let HTTPS secure the connection so the password is protected when the api is used.

Can this be considered secure?

  • 7
    Yes, the http user/pass will be OK as it goes over SSL, but the password has to be strong. Commented Jul 14, 2012 at 1:20
  • 3
    Well, i could put some logic in my server that bans a client that attempts too many passwords. Would that prevent DoS and password guessing?
    – Steven Lu
    Commented Jul 14, 2012 at 1:28
  • @StevenLu if that logic stores information about passwords somewhere that would adds to an attack surface
    – darw
    Commented Nov 7, 2023 at 12:43

9 Answers 9


There are a few issues with HTTP Basic Auth:

  • The password is sent over the wire in base64 encoding (which can be easily converted to plaintext).
  • The password is sent repeatedly, for each request. (Larger attack window)
  • The password is cached by the webbrowser, at a minimum for the length of the window / process. (Can be silently reused by any other request to the server, e.g. CSRF).
  • The password may be stored permanently in the browser, if the user requests. (Same as previous point, in addition might be stolen by another user on a shared machine).

Of those, using SSL only solves the first. And even with that, SSL only protects until the webserver - any internal routing, server logging, etc, will see the plaintext password.

So, as with anything it's important to look at the whole picture.

Does HTTPS protect the password in transit? Yes.

Is that enough? Usually, no. (I want to say, always no - but it really depends on what your site is and how secure it needs to be.)

  • 8
    actually, even with HTTP Digest, you may be able to a hash of the password (md5(username:realm:password), sometimes called HA1).
    – Bruno
    Commented May 18, 2011 at 20:58
  • 78
    @AviD♦ Imho your points 3) and 4) are rarely valid for REST APIs.
    – Eugene
    Commented Jun 22, 2012 at 19:55
  • 40
    @KimGysen for Basic Auth, the password is NOT transmitted or stored in a cookie, it is sent in the Authorization: request header, and stored in a special (protected) part of the browser's memory. Not that I disagree with you, in the general case Basic Auth should not be used, however there are certain situations where the tradeoff might be viable.
    – AviD
    Commented Nov 28, 2014 at 8:38
  • 10
    In addition to the "larger attack window," there's no built-in mechanism like account lock out to protect against brute forcing.
    – Alex Kuhl
    Commented Mar 6, 2015 at 16:08
  • 10
    @Artjom: Sending Basic credentials on every request is an issue, not because you have to keep sending the credentials, but rather because the same string is sent on every request. There are other authentication mechanisms, like HMAC, where the Authorization header cannot be decrypted back to the user's secret, and the server can authenticate the request without actually knowing the user's secret. In this mechanism, the string sent on the Authorization header changes based on the hash of the request.
    – Lie Ryan
    Commented Aug 6, 2015 at 14:28

Try to think of it this way: When you are logging in to any website using SSL, you are most likely passing password in plain-text over HTTPS (for eg GMail).

The only difference that Basic-Auth makes is that username/password is passed in the request headers instead of the request body (GET/POST).

As such, using basic-auth+https is no less or more secure than a form based authentication over HTTPS.

  • 60
    There is one slight difference between those situations: with http basic authentication the password is sent for every request, while with a form based login it is sent only once and then something like a session cookie is used. This very slightly decreases the attack surface. Commented Nov 4, 2015 at 10:51
  • 4
    The user password are sent only once but the auth cookie is sent on every request too, so the question is only to send the user and password instead cookie auth
    – deFreitas
    Commented Feb 8, 2016 at 12:46
  • 2
    @deFreitas and thus you have the premise of OAuth: using another token for auth instead of sending the u/p all the time.
    – cottsak
    Commented Mar 2, 2016 at 5:27
  • 22
    I think there is more than a slight difference: in the form POST example, the initial page rendering has to be sent over HTTPS before the user decides to enter their credentials and POST them back (securely). With HTTP basic auth, even if the server refuses to service a non-HTTPS request and redirect to HTTPS, the credentials have already gone over the wire insecurely and are then venerable to MiTM snooping. The client has to decide to POST HTTPS initially or risk an insecure channel. This is less likely with the form POST scenario.
    – cottsak
    Commented Mar 2, 2016 at 5:30
  • 6
    @PepijnSchmitz I would note the difference of a session key (which can be invalidated) is hugely different than having login credentials stolen. Damage can still be dealt while another party has your private session key, but it's much more limited in nature, especially since you can have your application log out from the API after it's finished executing to invalidate the key. Commented Aug 5, 2016 at 18:12

Basic Auth over HTTPS is good, but it's not completely safe. Similar to how Fiddler works for SSL debugging, a corporate HTTPS proxy is managing the connection between the web browser and the Proxy (whose IP address appears in your webserver logs). In that case the HTTPS password is decrypted, and later re-encrypted at the corporate proxy.

Depending on who is managing the proxy, and how its logs are used, this may be acceptable or a bad thing from your perspective.

For more information on how SSL interception is done, see this link:

When the SSL Proxy intercepts an SSL connection, it presents an emulated server certificate to the client browser. The client browser issues a security pop-up to the end-user because the browser does not trust the issuer used by the ProxySG. This pop-up does not occur if the issuer certificate used by SSL Proxy is imported as a trusted root in the client browser's certificate store.

The ProxySG makes all configured certificates available for download via its management console. You can ask end users to download the issuer certificate through Internet Explorer or Firefox and install it as a trusted CA in their browser of choice. This eliminates the certificate popup for emulated certificates...

Some companies get around the certificate pop-up issue mentioned above by deploying the root certificates (of the Proxy) to each workstation via GPO. Although this will only affect software that uses the Microsoft Certificate store. Software such as Firefox needs to be updated differently.

  • 3
    The negative voter should read the linked documentation, since this is a real and valid point that isn't broadly known. Docs: bluecoat.co.jp/downloads/manuals/SGOS_DG_4.2.x.pdf Commented Dec 7, 2010 at 3:40
  • 5
    Yeah, you're right - BlueCoat does look like corporate malware, using FUD to make business insecure.
    – AviD
    Commented Dec 7, 2010 at 9:00
  • 2
    And btw - Chrome does use the Windows Certificate Store...
    – AviD
    Commented Dec 7, 2010 at 9:01
  • 3
    @AViD, there are some cases where corporate proxies actually do decrypt the SSL traffic, by presenting their own certificate (which is signed by an internal corporate cert that is imported as a trusted root authority cert on all corporate workstations). My company does this for a few sites including Gmail (but not for banking sites). It works, and is often invisible to users because the company also manages the desktops/browsers. Note that Strict Transport Security (HSTS) can defeat this ... it was the firefox HSTS warning that alerted me to it in the first place! Commented Dec 17, 2015 at 17:28
  • 2
    If the company does MITM attacks on employees traffic it defeats almost any form of authentication, not just Basic Auth. So unless the web server is willing to use something more complex like 2-factor auth, Basic is almost as secure as any other form of authentication.
    – Poma
    Commented Jan 11, 2019 at 12:30

You note the need for authenticating the client and ask about the security of HTTP basic auth, over SSL. This is what SSL was designed for and will work fine so long as the password is a good one. If you're really setting this up for just a single client, that is easy to ensure by picking a long random password, e.g. 12 characters using a good source of randomness, or other techniques discussed at this site.

Your client also does need to ensure that you have the right cert for the server. In the situation like what you describe, using a self-signed cert as described at the python ssl page referenced will be fine.

  • 2
    If you are going self signed, be sure to communicate what the SHA1 and MD5 fingerprints of the certificate should be so they can verify its legitimacy upon connection. Or distribute ahead of time, if feasible.
    – chao-mu
    Commented Jul 14, 2012 at 3:27
  • 2
    There is another concern with using HTTP basic authentication: the full password is sent over the SSL tunnel. In other words, the password is not hashed before being submitted, and could thus possibly be captured (bug in your application code, etc). This is usually not a major concern (this is true for most passwords you submit over HTTPS, even in website login forms, and even in password SSH), but is worth taking note of. Commented Jul 14, 2012 at 4:43
  • @ChrisKuehl Aren't there strong arguments against doing any crypto in client-side javascript? Is that what you are suggesting? Seems to me like TLS is about as good as I can get other than paying for signing the certificate.
    – Steven Lu
    Commented Jul 14, 2012 at 9:23
  • @StevenLu not that I'm aware of or that I can find quickly, but I'd be interested in reading anything about the topic. I can't see any way that hashing something preliminarily before sending it serverside could decrease security, even if serverside further hashes it before storing it. I would be tempted to use SSL/TLS auth instead (modern browsers allow 2-way auth with websites using key auth), especially for a page that is not meant to be viewed by regular users. This depends a lot on your use case, though, and is probably difficult with your Python webserver. Commented Jul 14, 2012 at 17:08
  • 1
    @StevenLu interesting, but missing the point; TLS auth, as implemented in browsers, doesn't involve JavaScript. It's a feature of the browser itself. There are issues that make it not suitable for use with user-facing authentication, but for developers/admins, I think there's a strong case that can be made for it. Commented Jul 14, 2012 at 23:00

Depends entirely on how secure it needs to be. Basic auth over ssl will still be sending credentials in plain text, which means you only have one layer of protection.

You would be better off to hash the password with a nonce, or better yet use claims model that passes the auth over to a trusted 3rd party.

  • 1
    When you log in to gmail.com, it also sends the password as plain text over https doesn't it? Commented May 29, 2022 at 11:56
  • But then, you only log once, and gmail also has the timestamp telling you when you have last been active. Now, go and guess why Commented Feb 14, 2023 at 14:13

I am using this myself for many things, and as long as you don't ignore any TLS warnings from the browser you should be good.

TLS works below HTTP, so any data transmitted through HTTP will be encrypted. It'll be as secure as submitting any password form.

Instead of using a self-signed certificate though, I would suggest using Let's Encrypt. They provide free certificates and are trusted by Microsoft, Mozilla, etc., and thus it won't give a TLS warning in the browser. I think it's better to use this instead of a self-signed certificate; if you ever see a TLS error you know it's real and not just because your cert is self-signed.

  • I'd definitely do something like this especially if it's free. The "invalid certificate" errors are pretty glaring.
    – Steven Lu
    Commented Jul 15, 2012 at 1:08
  • Yes, StartSSL is really a sorta homebrew solution, but it's trusted by big parties so I guess it's fine as long as you don't secure anything worth millions with it. Anything is better than a self-signed certificate. The way to make self-signed secure is to check the fingerprint, but you can still do this while using (for example) StartSSL.
    – Luc
    Commented Jul 15, 2012 at 17:59
  • I am hosting my secure content on a different server from one which I can set the target domain for a certificate (to be issued by StartSSL). This is because I am not paying for a VPS with a static IP, I am using the No-IP service to give me a redirect to my IP. Is it possible for me to obtain a key/certificate that will allow me to open my site from anywhere without it showing invalid cert errors?
    – Steven Lu
    Commented Jul 17, 2012 at 3:54
  • So it seems to be clear to me that with a dynamic IP there is absolutely no way to set up a proper SSL certificate. Okay I guess I am stuck with the browser error then (unless I do some kind of proxy setup).
    – Steven Lu
    Commented Jul 17, 2012 at 4:02
  • 1
    @starbeamrainbowlabs Thanks! I updated the answer.
    – Luc
    Commented Dec 17, 2017 at 12:35

Plenty of large and popular sites use basic (or another forms-based) auth over HTTPS. It usually gets a 'sigh' from security-conscious people. Can you hash the password on the client-side and send the hash instead? That would raise the bar a bit more.

That said, it's generally considered acceptable, under the condition that your landing page hosting the logon form is HTTP/S as well. In your case of a RESTful API you probably don't have a landing page so that's okay. If you can, verify your application with some free security tools like Watcher and Skipfish.

  • 6
    only a challenge-response with hash is an upgrade in security, otherwise the attacker can just snoop the hash and still get access when the session expires Commented Jul 19, 2011 at 22:14

Another argument not mentioned (I guess) so far is the fact that many mobile devices such as smart phones do not let the user check the certificate when doing basic auth over HTTPS in the browser. That means that unlike with forms based auth you cannot bypass the basic auth popup which is a modal dialog on most mobile platforms to check the certificate before you enter your credentials. This might pose a risk when an attacker uses a valid certificate.


Quoting the spec https://datatracker.ietf.org/doc/html/rfc7617#section-4

Because Basic authentication involves the cleartext transmission of passwords, it SHOULD NOT be used (without enhancements such as HTTPS RFC2818) to protect sensitive or valuable information.

MDN makes a similar comment https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication#security_of_basic_authentication

As the user ID and password are passed over the network as clear text ... the basic authentication scheme is not secure. HTTPS/TLS should be used with basic authentication.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .