Tesla Model S REST API Authentication Flaws

As many of you know, APIs matter to me. I have lightbulbs that have APIs. Two months ago, I bought a car that has an API: The Tesla Model S.

For the most part, people use the Tesla REST API via the iPhone and Android mobile apps. The apps enable you to do any of the following:

  • Check on the state of battery charge
  • Muck with the climate control
  • Muck with the panoramic sunroof
  • Identify where the hell your car is and what it’s doing
  • Honk the horn
  • Open the charge port
  • Change a variety of car configuration settings
  • More stuff of a similar nature

For the purposes of this article, it’s important to note that there’s nothing in the API that (can? should?) result in an accident if someone malicious were to gain access. Having said that, there is enough here to do some economic damage both in terms of excess electrical usage and forcing excess wear on batteries.

The Authentication Protocol

The authentication protocol in the Tesla REST API is flawed. Worse, it’s flawed in a way that makes no sense. Tesla ignored most conventions around API authentication and wrote their own. As much as I talk about the downsides to OAuth (a standard for authenticating consumers of REST APIs—Twitter uses it), this scenario is one that screams for its use.

Authentication happens when you call the /login action with the email address and password of the Tesla customer. This is the same email address and password used to log into www.teslamotors.com. Every customer has one because this website is where the customer builds their car.

The authentication action creates a “token” that is valid for 3 months. Any further requests use that token for validation. You don’t use the email address/password again until the token expires in 3 months (assuming you store the token somewhere).

This model suffers from the following flaws:

  • It cannot safely operate over any channel but a trusted SSL connection (minor)
  • It requires the sharing of the user’s password with third-parties (major)
  • No mechanism exists for cataloging applications with active tokens (significant)
  • Only an inconsistent blunt-force mechanism exists for revoking access to a compromised application (moderate)
  • No mechanism exists for revoking the access of a compromised application (major)
  • The automated expiration of tokens in 3 months encourages applications to improperly store your email and password (significant)

Potential Attack Vectors

There’s no immediate danger from this architectural flaw that compromises the safety of the Model S. However, it does open up the following potential attacks:

  • You want to leverage a tool on a web site with some useful functionality. You enter your email/password. They willfully and incorrectly store that information and are subsequently compromised (or worse, they use it themselves).
  • An attacker gains access to a web site’s database of authenticated tokens. It has free access to all of that site’s cars up to 3 months with no ability for the owners to do anything about it unless the user changes their TeslaMotors.com password, in which case access for all third-party applications is revoked give or take some unspecified caching interval.

As noted above, the impact of any of these very real attack vectors is pretty much economic. I can target a site that provides value-added services to Tesla owners and force them to use a lot more electricity than is necessary and shorten their battery lives dramatically. I can also honk their horns, flash their lights, and open and close the sunroof. While none of this is catastrophic, it can certainly surprising and distracting while someone is driving (though not all functions are supported remotely while the car is in motion).

Perhaps the scariest bit is that the API could be used to track your every move.

The core issue, however, isn’t how bad an attack could be as a result of these specific flaws. Instead, I’m commenting on the larger picture of the Internet of Things in which everything has an API and everything needs to be secured reasonably. I don’t think the Tesla software engineers have given the security of the REST API its proper due and I see a common theme among Internet-connected “things” (the Hue being a good example) of not thinking through the security impacts of what they are doing.

What’s truly stupid here is that there was no reason for Tesla to write their own API authentication. There are, IMHO, two common models for API authentication:

  • User-to-system (as is the case with the Tesla API)
  • System-to-system

OAuth is the proper authentication mechanism for User-to-System authentication, and it’s truly unfortunate that Tesla ignored it.

Other Notes

  1. Applications don’t talk directly to the car. They talk via a web portal that processes requests and sends them on to the car. As far as I can tell (with very limited visibility), Tesla keeps a very strong security separation among the various operational components of the car.
  2. This is NOT about Tesla in the end. It’s about how we should be approaching API design in a world in which everything has an API. Hint: it starts with security and ends with the functionality, not the way Tesla, Hue, and most people are doing it today.
  3. Hue has a much easier to exploit flaw, but all an attacker can do is turn on/off lights and change their colors.


People have gotten a variety of inconsistent results from testing token revocation. Because it does sometimes work for sure, I’ve made some changes noted above to the original article. My best guess is that the inconsistent results are because of some kind of caching mechanism, but it doesn’t explain why in some cases the tokens have remained active for hours/days beyond a password change.

Either way, brute force removal of access for all applications isn’t the proper way to handle revocation for connected devices and that doesn’t impact all of the other issues.


Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
topic: Web Platform
  • Patrick Niemeyer

    This is total and complete nonsense: “It requires the sharing of the user’s password with third-parties (major)” – No, nobody on earth has ever suggested that you should do that, least of whom I’d imagine would be Tesla. So their undocumented API used only in their own app was not designed for you to share your credentials with a third party, so why would you do that? Your argument boils down to – there is an API for my car so if I give some random guy my password they could use this API to mess with my car!

    And you appear to be technically incorrect on this: “It has free access to all of that site’s cars up to 3 months with no ability for the owners to do anything about it.” You seem to be basing this on the idea that the token declares itself valid for three months. But if you simply change your password on the site it appears to invalidate the token on the server side. Try using the iPhone app and then changing your password on the server. After a few minutes the iPhone app will make you log in again.

  • flasherz

    First, it is rather unfortunate that the original article for this published on August 21, the one picked up by the press and sensationalized, has comments disabled so that the errors of omission could be noted before the press ran with the implication George delivered — which was that the Tesla product was inherently flawed.

    What George fails to point out is that the API George refers to is a CLOSED API that was reverse-engineered from the mobile app by some very bright people. The API as it exists has never been published by Tesla, nor was it intended to be as-is. It was purely a way for the mobile app to communicate with Tesla’s servers. Since decoding it, developers have added a lot of value in their own personal programming, but it does preclude third parties from securely offering services (like a “teslastats.com”, for example) — an architectural choice by Tesla in the release of its app.

    If you use only the Tesla mobile app, you are in no danger. If you don’t use any third-party apps that use an unpublished, closed API while having to store your credentials to monitor your Tesla, you are in no danger. You cannot be “hacked”.

    What is rather ironic here is that George attacks Tesla for not having an open-enough API, instead of giving Tesla credit for designing its closed mobile API to be opened up in the future, perhaps when they can work out the authentication issues that are noted. George purports to be a proponent of an open API world, but his actions here are likely to make Tesla to close the API’s, rush to put out new mobile apps, and change the server code so that the API can’t be used anywhere but the official mobile apps — exactly the opposite of his “premise” that the world should be completely open.

    I would be standing right next to George and shouting from the rooftops of the architectural problems *IF* Tesla had published the API as an open, public API; it didn’t, however.

    The press has been misled due to an omission of error, and unfortunately, George (in another forum) chose not to change the original post – instead stating an intent to publish the virtual equivalent of a page 21 retraction follow-up. With a press so eager to feed on bad news, do you think the clarification will be picked up? I don’t believe so.

    Finally, as noted by Patrick (below) — there’s nothing that can be done about a user who willingly gives their username & password credentials to anyone but Tesla… that’s no different than Facebook, Twitter, etc.

    • Jann Van Hamersveld

      He also has no understanding of the basic safety protocols setup to prevent the vehicle from communicating while in motion. He seems to think that the communication between the client and the head-unit is direct, which it is definitely NOT.

      • GeorgeReese

        Actually, the article says it doesn’t.

        The vehicle does, by the way, communication while in motion. It communicates all sorts of useful information. And I’ve done fun things like open the sunroof via the API while the car is in motion over the public Internet.

  • Bill Burke

    While OAuth 2 does have the idea of refresh tokens, AFAIK, revocation and blacklisting are not part of the protocol and are actually out-of-band.

    Also, some of the attack vectors you specify also can happen within OAuth too if token expiration is long and applications store them.

  • GeorgeReese

    People linking devices and web services is a fact of the reality in which Tesla is trying to participate. The fact that this API is not published is immaterial. It is an API that is active in the wild and a valuable ecosystem is growing up around that reality.

    I will write more specifically about the folly of “unpublished web services APIs” as a follow-up.

    The fact nevertheless remains: there exists a standard for authenticating systems of this type, OAuth. Tesla opted to use a custom authentication scheme instead of OAuth and this custom authentication scheme leaves the Tesla ecosystem vulnerable.

    The whole “you should not share your credentials” with third parties is sheer nonsense. The Internet of Things demand that different web services and devices have access to each other. And while Tesla may not have planned on it, the Internet of Things has grown with and without permission. In fact, the online banking example is a great one. People give their credentials to third parties all the time, long before banks were complicit in it.


      Hi George, I disagree with your statement that it is ok to share your credentials with 3rd party applications. Yes, people do it all the time. But is it the right thing to do? No.

      Standards such as OAuth have been created to reduce the need to share credentials around. Credentials are kind of long lived whereas authorization tokens can be revoked by the user and access tokens have short life time.

      While it is extremely hard to rid the world off passwords, we should push for open standards and use of well researched and accepted tokens. I think you mention this in your article.

      • GeorgeReese

        Perhaps I could have been clearer in my wording. I’m not openly advocating that it’s OK to willy-nilly give out your login credentials. In fact, I am arguing that people who build systems shouldn’t force their users to make the choice between convenience and security. That’s why I am taking Tesla to task.

        I believe the admonition not to share your credentials with third-parties is nonsense because I think it’s the same as saying “If you want to be secure, disconnect from the network”. People need to do work on the network, so disconnecting is silly advise. We find way to make being on the network acceptably secure.

        Similarly, people need to enable value-add services and devices to interconnect with their cloud services and other devices. If they are not given an alternative, then they will share their login credentials. Responsible behavior therefore dictates that people building cloud services and devices make sure that people aren’t forced to give out their login credentials in order to support this connected world.


          Yes, completely agree on your last paragraph. Unless practitioners, architects and system owners do the right thing, users will not hesitate to share/use their credentials (and PII).

          Thanks for clarifying your original comment.

    • Bill Burke

      My problem is that you imply that if Tesla used OAuth (2?) all their problems would be solved:

      “It cannot safely operate over any channel but a trusted SSL connection (minor)” – Neither can OAuth

      “No mechanism exists for cataloging applications with active tokens (significant)” – OAuth does not define this either

      “No mechanism exists for revoking the access of a compromised application (major)” – Same is true for OAuth!

      “The automated expiration of tokens in 3 months encourages applications to improperly store your email and password (significant)” OAuth suggests but does not require short-lived tokens. Also, OAuth offers a direct option of getting tokens from a user/password.

      • GeorgeReese

        Adopting OAuth in the manner that is customary for OAuth implementations deals with the issues I address. More to the point, it provides standardized mechanisms through which they can be addressed. Only a bozo implements OAuth in a way that doesn’t address these issues.

  • Paul Walker

    What the author fails to mention, I can only assume out of ignorance, is that the latest OAuth protocol actually supports API authorization via user supplied credentials in the http request in order to obtain a token. The decision to support this particular “password” “grant_type” is outside of the scope of the specification, but the fact is that it is included for just such a use case as that of Tesla: a trusted client let alone a private-closed API. While it is supported for Tesla’s private client, that does not mean Tesla will have to support this grant_type flow for future 3rd parties.

    Given the fact that Tesla has not publicized a public API for 3rd parties, it is really quite reasonable that they do not provide a user dashboard for revocation of tokens.

    Also not mentioned is the fact that Twitter’s initial 3rd party API implementation ONLY supported an authorization workflow in which the 3rd party client had to take input for user credentials. And again, this was an official 3rd party API at the time. One may argue that OAuth was in it’s infancy, but the concept of delegated authorization certainly was not. Oh, and it took several years before Twitter deprecated that.


      Hi Paul, more than the OAuth spec infancy, I think it was the clumsiness of mobile environments to do the OAuth handshake that forced many 3rd party mobile apps to request user’s credentials to use with twitter api. Also it was easy for 3rd party apps to use username/password combo rather than go through the complex oauth workflows.

      I am glad that phase of the industry is over with twitter deprecating API direct credential usage and mobile environments doing a better job at user experience during the oauth authorization workflow.

      • Paul Walker

        Sure, there were arguments regarding the clumsiness of the authorization workflow in oauth in general, but my point was simply to point out the author’s inconsistency in putting Twitter’s api implementation on a mantle while simultaneously tearing down that of Tesla. 3rd party developers did not implement credentialing input out of UX choice when Twitter initially launched…if I remember correctly Authorization: Basic was the only method for quite some time.

        • GeorgeReese

          I’m not putting Twitter on a mantle here. I think Twitter’s incompetence that resulted in security chaos and later success with OAuth serve as a good example of what happens when you don’t protect against third-parties seeing credentials and how something like OAuth can address the problem.


    Tesla should act as the Identity Provider and use standards (SAML or OAuth + JWT) to provide access to user’s car resources to 3rd party apps on user’s approval. Sending tesla credentials to 3rd party apps is a disaster in the making.

    • flasherz

      Hi Anil, a point the author fails to state is that this API has never been published for 3rd party apps to consume. It is a private API for use between Tesla’s official web apps and Tesla’s vehicle communication capabilities. As a result, you really can’t fault Tesla (yet, until it’s published) for how they authenticate their own users.

      If the API were intended and published as an open API, I’d agree with you.


        I agree with you. But Tesla still look at using standards rather than private implementations. :)

        Thinking further on this, I think Tesla should shut down the API endpoint right away, reset user’s credentials and use some second factor that establishes the requests are coming from Tesla’s official mobile app. Safeguarding Tesla’s mobile code seems to be issue here (I do not have an answer for that).


          Given that the interaction between user (Tesla official mobile app) and Tesla Web System happens over a mutually authenticated SSL connection (MASSL), I wonder how the 3rd party mobile applications are able to circumvent the MASSL requirement.

          • flasherz

            It is not via a mutually authenticated SSL connection. Tesla’s server does not require SSL authentication.

  • Jann Van Hamersveld

    I stare at these protocols everyday and the entire article is complete bullshit. George, you have no idea how telematics systems work.

  • GeorgeReese

    Update on Token Expiration

    It seems people are getting mixed results on token expiration (myself included). My best guess is that there’s some caching thing going on here.

    Assuming the best case (tokens should not be subject to this kind of caching however), where the list of issues was formerly:

    1. It cannot safely operate over any channel but a trusted SSL connection (minor)
    2. It requires the sharing of the user’s password with third-parties (major)
    3. No mechanism exists for cataloging applications with active tokens (significant)
    4. No mechanism exists for revoking the access of a compromised application (major)
    5. The automated expiration of tokens in 3 months encourages applications to improperly store your email and password (significant)

    #4 should be altered to be:

    Only an inconsistent blunt-force mechanism exists for revoking access to a compromised application (moderate)

    And actually, #5 should be updated to be:

    5. The automated expiration of tokens in 3 months along with the blunt-force token revocation mechanism encourages applications to improperly store your email and password (significant)

  • David VomLehn

    “Perhaps the scariest bit is that the API could be used to track your every move.”

    Nah, nobody cares where I go. But:

    ” I can … open and close the sunroof. While none of this is catastrophic…”

    If you can open my sunroof, you can take anything in my car without a key. Possibly not catastrophic, but a very big deal, indeed.

    • Stephen Pace

      @David: The API only lets you ‘vent’ the sunroof a tiny bit (pivoting it up slightly). It doesn’t use the ‘open’ mechanism which slides it back. No one will be able to take your stuff in ‘vent’ mode. The only real issue is if it were raining, and even then, the car could easily be programmed to avoid doing that if the rain sensor detected rain (if it doesn’t do that already, I haven’t tried).

      • David VomLehn

        Ah, this makes me feel a bit better!

  • Gavin Johnson

    I don’t think TESLA have done too much harm here. Their API isn’t Public, not does it need to be. Neither is it Private (aka internal) which means its a Partner API. The argument against TESLA seems to be that they should have added more transparency around their Partner API – e.g. through publication. It really depends on the TESLA business model. Publication has a higher overhead, but can lower integration costs if the API has a lot of partners. This API seems like a smaller, experimental piece of work and the approach TESLA have taken feels appropriate.