Accidental API Key Exposure is a Major Problem
rosspenman.com
Accidental API Key Exposure is a Major Problem
1–10 of 16 posts
Re: Accidental API Key Exposure is a Major Problem
#2If you develop a API that requires a key, is there any secure way of allowing third party developers to develop client applications that use your API?
It seems like a malicious party could just view the source of the client app and see the key and hijack it.
Re: Accidental API Key Exposure is a Major Problem
#3Nice article, Ross. This is definitely a huge issue that many developers face. I did a similar search for Twilio keys and many of those accounts had hundreds if not thousands of dollars worth of Twilio credits ready for use by a malicious attacker. It just comes to show how simple most of these mistakes are while still being very serious
Re: Accidental API Key Exposure is a Major Problem
#4If you develop a API that requires a key, is there any secure way of allowing third party developers to develop client applications that use your API? It seems like a malicious party could just view the source of the client app and see the key and hijack it.
Yes. That's true - if your source code is exposed to a client.
Going back to my example of Twilio apps, usually the code that interacts with Twilio is on the server side, so you couldn't find the API keys by viewing source.
Re: Accidental API Key Exposure is a Major Problem
#5I think there are two root problems here; the first is human error/forgetfulness, and there's only so much you can do about that.
The second, which I see on a daily basis from a small number of my colleagues, is a lack of understanding about security - by way of an example, we distribute a script to commercial partners that I've regularly had to expunge passwords for our Subversion repo from. Trying to explain the problem to the culprit gets nowhere because 'well, they can't access the repository without using our VPN', which of course is very far from the point... but nearly impossible to argue against without lecturing.
Re: Accidental API Key Exposure is a Major Problem
#6If you develop a API that requires a key, is there any secure way of allowing third party developers to develop client applications that use your API? It seems like a malicious party could just view the source of the client app and see the key and hijack it.
Yes. That's true - if your source code is exposed to a client. Going back to my example of Twilio apps, usually the code that interacts with Twilio is on the server side, so you couldn't find the API keys by viewing source.
Another thing we (Twilio employee here) do, for our Client product, which runs on iOS and Android, we use a different form of authentication: we require a server-side component to generate a "capability token" which is signed by your main auth token. The capability token is limited in what it can do, and expires after a configurable amount of time, so if an attacker gets hold of one, the damage they can do is limited.
Of course, people can "cheat" and put their auth token and a capability token generator in their mobile app, but we try to discourage that use.
Re: Accidental API Key Exposure is a Major Problem
#7I think there are two root problems here; the first is human error/forgetfulness, and there's only so much you can do about that. The second, which I see on a daily basis from a small number of my colleagues, is a lack of understanding about security - by way of an example, we distribute a script to commercial partners that I've regularly had to expunge passwords for our Subversion repo from. Trying to explain the pr…
I think another thing is that calling it an "API key" gives a slightly different impression from "password" - the latter almost certainly implies something that should be kept secret, while it's not so clear with the former - for example, ReCAPTCHA API keys are very much publicly available in the source of whatever pages use them.
Re: Accidental API Key Exposure is a Major Problem
#8API key of any downloadable application should be considered as “public”. Removing it from public source code just makes harvesting a bit harder, but it's still possible. So if API key of such applications is so important — it's just a bad service design.
Re: Accidental API Key Exposure is a Major Problem
#9Earlier quoted context omitted.
Yes. That's true - if your source code is exposed to a client. Going back to my example of Twilio apps, usually the code that interacts with Twilio is on the server side, so you couldn't find the API keys by viewing source.
Another thing we (Twilio employee here) do, for our Client product, which runs on iOS and Android, we use a different form of authentication: we require a server-side component to generate a "capability token" which is signed by your main auth token. The capability token is limited in what it can do, and expires after a configurable amount of time, so if an attacker gets hold of one, the damage they can do is limited…
I am loving Firebase's serverless model of application development, so that server solution is not ideal.
But I don't think its possible to solve a different way. That said, there are smart people who have thought of ways of reducing server burden in ways I never thought possible (like encrypted sessions), so it might be possible ???
How does google analytics stop rogue clients registering hits on the wrong domain? It checks the domain the incoming data is on, right? (cookies?)
Re: Accidental API Key Exposure is a Major Problem
#10It's not just a problem for "open source" applications, it's a problem for "closed source" applications too. In a large team you don't want to give every developer the keeps to the jeep.