API security leaves apps vulnerable: 5 ways to plug the leaks

Many Starbucks customers got a jolt in May when cyberthieves were discovered stealing money from their credit cards and payment accounts by first tapping into their Starbucks mobile apps. The culprit was believed to be a hole in an application-programming interface (API), though perhaps not on Starbucks' site but on another app where overused passwords were stolen and reused, according to reports.

Greeting card website Moonpig and mobile app Snapchat have suffered similar fates at the hands of API, the set of requirements that govern how one application can talk to another and what data it can access.

In January, an unsecured API caused Moonpig to expose personal records and partial credit card details for some 3 million customers. Two exploits in Snapchat's API allowed hackers to mass-match phone numbers with names and to create millions of bogus accounts.

Why are APIs becoming the target of hackers? Because they're everywhere, says Randy Heffner, API security analyst at Forrester Research. Just about every company is building APIs to support their web or mobile application because it allows them to innovate faster and bring outside content in.

There are more than 13,700 publicly available APIs offered by firms today, according to programmableweb.com. Salesforce.com generates 50 percent of its revenue through APIs, Expedia.com generates 90 percent, and eBay attributes 60 percent of revenues to APIs.

"The broader attention to APIs gives hackers a new and more interesting playground to [pursue]," Heffner says.

Most APIs are available to anyone on the Internet because they run on web servers. Just like websites, APIs can be crawled by search engine bots and hackers.

API security is an area that deserves specific enterprise scrutiny, Heffner adds. "We don't want any submarine APIs -- running silent, running deep -- because if someday hacks your home site you see it pretty quickly. If somebody hacks an API you may not see it at all."

Why are security flaws popping up in APIs?

For starters, developers are not security pros, and speed to market affects any kind of testing and due diligence that coders can do around their code. "They spend a lot more time bringing value in the apps than on the security side," which can lead to security leaks, says Allyn Fay, technical marketing manager at identity and access management vendor Ping Identity.

There is also very little communication between API developers, which discourages security standards.

"In every company, each business unit has the mandate to publish APIs, and they don't talk to each other," says Subra Kumaraswamy, head of product security for API platform developer Apigee. "If I'm a business unit that's doing shipping, or a payment company doing payment APIs," we're not comparing notes, he adds.

What's more, developers are under pressure to innovate faster, which can also create vulnerabilities in the process, Kumaraswamy says. "You have an opportunity to make mistakes in exposing data inadvertently, or you're not putting the right controls in the API."

Plugging the leaks

App development shows no signs of slowing down, but companies can take steps to plug the leaks in APIs.

When it comes to securing applications versus APIs, "in Web apps you typically only have to authenticate the end user. In the API world you also have to authenticate the app," Kumaraswamy says. For instance, "If you're using the AirBnB or the Uber app, these apps are calling their APIs so those apps are being authenticated."In the case of Moonpig -- authentication was enforced, but authorization was not, he adds.

Using a standardized protocol that exists for both authentication and authorization are the jumpstart to using APIs securely, Fay adds. "If you do them the right way, the amount of security built in is based on the standard" and won't vary from app to app.

2. Encrypt transports

Always encrypt sensitive data, Heffner says. Never create a security hole by using plain text transfers. Developers should use SSL certificates on web APIs that transfer sensitive data between the end-point program and the web service interface because hackers can sniff this data. If you make your API a subdirectory in your current web application, you can use the same security certificate that you have for your website.

3. Protect credentials 

Know how credentials are managed for the app and how critical they are for the particular kind of business scenario, Heffner adds.

"If I were a bank doing financial transactions with a partner, there's a number of layered connections I would want to have, like a VPN to SSL or I would have digitally signed tokens -- SAML or the like, as part of the full security scheme." With multiple security mechanisms in place, "it's raising the bar on the number and kind of things someone would have to do to spoof any connection."

Digitally signed tokens can also be one part of the security scheme. Tokens are character strings that uniquely identify a user. You can store these strings in a database and only give access if the user enters the correct user name and password. The token is then used by the API user to access an API's methods.

4. Avoid static or embedded passwords

When logic is built into an app, it's very difficult to change, Fay says. When you want to change a policy or update security, having all of that logic built into mobile apps is not a good thing. So developers sometimes take shortcuts with easy passwords or by caching IDs and passwords locally on a mobile app, and that's a huge problem from a security standpoint. "Static passwords are to be avoided," Fay says.

5. Expose only required information to your API  

Developers will often take all the information they have on a user and give it to the API because they don't know what data is required, Fay says. "Make sure you're only moving the data that you need to," he says. "It's more of a privacy issue than a security one," but it could be used in social engineering schemes.