Securing APIs Samuel Warren IS469-Information Security Capstone Dan Morrill City University April 27, 2012 Securing APIs Executive Summary There is an increasing demand on the enterprise API used by our organization. Keeping this in mind, our security needs to be updated to ensure no sensitive data is released to the public. There is one change that is recommended to more securely protect our API. Introduction Application Programming Interfaces (API) have been around for quite some time. When web applications were created, by necessity, so were APIs. While the API has taken recent changes in usage, the core idea is the same. APIs are the access point to the application for the developers to work. With the current desire to use a group of people to make projects better, API security has been under heavier fire. Prior to the demand for application sharing, API security was not a high priority simply because most of the application support was done inside the same relative zone on the network, all of which was typically secured private networks. However, with the increase in demand, every aspect of each API is being put under more scrutiny than its predecessors. With that in mind, the following is a recommended change to the current enterprise API. Recommended Changes to API Because of the demand on all API features and the amount of legitimate traffic coming to the application tier, the proposed solutions should meet both now and future API traffic. The recommendation is to create a custom checksum that is hashed values of the session data and private key. When the client sends the packet to the server, the server then takes the file, compile’s its version of the same checksum, and verifies that it matches. You realize that in real-life, this is basically like someone coming up to you and saying: “Jimmy told me to tell you to give the money to Johnny Two-toes,” but you have no idea who this guy is, so you hold out your hand and test him to see if he knows the secret handshake. (Kalla, 2011) If our systems can come up with a secure, hashed, match to the provided checksum, the internal application tier can grant trust to the requestor. This is called “HMAC” (Kalla, 2011) authentication and does not require any direct send of password or username over un-encrypted channels. For more information about securing APIs, please make use of the References section. References Kalla, R. (2011, April 26). Designing a Secure REST (Web) API without OAuth [White Paper]. Retrieved April 27, 2012, from The Buzz Media; Video Games, Movies, and Technology. website:http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/