Accidental API Key Exposure is a Major Problem

I had this same issue when I started working on a side project. I quickly decided to store the Github API secret and client id in a property list, and then access it from there in the code. The keys are never exposed in the code and that&#x27;s great. The property list file was ignored by my github repository and all was well with the world.<p>Until I started using a CI server, which would fail to compile because that file was no longer present when it was described in the project configuration. To fix this, I added a blank copy of the configuration file to the repository, committed that so that the project would compile on Travis, then ran `git update-index --assume-unchanged` to never update that file again, so that I could fill in the correct configuration data again.

API key of any downloadable application should be considered as “public”. Removing it from public source code just makes harvesting a bit harder, but it&#x27;s still possible. So if API key of such applications is so important — it&#x27;s just a bad service design.

I think there are two root problems here; the first is human error&#x2F;forgetfulness, and there&#x27;s only so much you can do about that.<p>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&#x27;ve regularly had to expunge passwords for our Subversion repo from. Trying to explain the problem to the culprit gets nowhere because &#x27;well, they can&#x27;t access the repository without using our VPN&#x27;, which of course is <i>very far from</i> the point... but nearly impossible to argue against without lecturing.

It&#x27;s not just a problem for &quot;open source&quot; applications, it&#x27;s a problem for &quot;closed source&quot; applications too. In a large team you don&#x27;t want to give every developer the keeps to the jeep.

Bizarre that nowhere does this article say you must invalidate the key. Lots of people could well have pulled a branch with the key, and rewriting history will make this very obvious.

Nice 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

If 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?<p>It seems like a malicious party could just view the source of the client app and see the key and hijack it.