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\u2019 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\u2019s 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\u2019re 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\u00a0more than 13,700 publicly available APIs offered by firms today, according to programmableweb.com. Salesforce.com generates 50 percent of its revenue through APIs,\u00a0Expedia.com generates 90 percent, and eBay attributes 60 percent of revenues to APIs.\u201cThe broader attention to APIs gives hackers a new and more interesting playground to [pursue],\u201d 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. \u201cWe don\u2019t want any submarine APIs \u2013 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.\u201dWhy 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. \u201cThey spend a lot more time bringing value in the apps than on the security side,\u201d 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.\u201cIn every company, each business unit has the mandate to publish APIs, and they don\u2019t talk to each other,\u201d says Subra Kumaraswamy, head of product security for API platform developer Apigee. \u201cIf I\u2019m a business unit that\u2019s doing shipping, or a payment company doing payment APIs,\u201d we\u2019re not comparing notes, he adds.What\u2019s more, developers are under pressure to innovate faster, which can also create vulnerabilities in the process, Kumaraswamy says. \u201cYou have an opportunity to make mistakes in exposing data inadvertently, or you\u2019re not putting the right controls in the API.\u201dPlugging the leaksApp development shows no signs of slowing down, but companies can take steps to plug the leaks in APIs.Authorize the user and authenticate the appWhen it comes to securing applications versus APIs, \u201cin Web apps you typically only have to authenticate the end user. In the API world you also have to authenticate the app,\u201d Kumaraswamy says. For instance, \u201cIf you\u2019re using the AirBnB or the Uber app, these apps are calling their APIs so those apps are being authenticated.\u201dIn the case of Moonpig \u2013 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. \u201cIf you do them the right way, the amount of security built in is based on the standard\u201d and won\u2019t vary from app to app.2. Encrypt transportsAlways 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\u00a0Know how credentials are managed for the app and how critical they are for the particular kind of business scenario, Heffner adds.\u201cIf I were a bank doing financial transactions with a partner, there\u2019s a number of layered connections I would want to have, like a VPN to SSL or I would have digitally signed tokens \u2013 SAML or the like, as part of the full security scheme.\u201d With multiple security mechanisms in place, \u201cit\u2019s raising the bar on the number and kind of things someone would have to do to spoof any connection.\u201dDigitally 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\u2019s methods.4. Avoid static or embedded passwordsWhen logic is built into an app, it\u2019s 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\u2019s a huge problem from a security standpoint. \u201cStatic passwords are to be avoided,\u201d Fay says.5. Expose only required information to your API \u00a0Developers will often take all the information they have on a user and give it to the API because they don\u2019t know what data is required, Fay says. \u201cMake sure you\u2019re only moving the data that you need to,\u201d he says. \u201cIt\u2019s more of a privacy issue than a security one,\u201d but it could be used in social engineering schemes.