Digital blog

Opening up your APIs and keeping the cybercrooks out

Open application interfaces (APIs) make the consumer experience smoother—but they also increase the risk to customer and business data. From the IRS to major manufacturers, smart organizations are upgrading their security strategies to protect themselves and their customers from hackers and other digital criminals. Here’s how they start.

by Srinivas Ramadath

When I talk to business leaders these days, I hear two things: everybody wants to figure out how they can profit from the application interface (API) economy, and everybody is concerned about API security. Whether they are in retail, financial services, or manufacturing, companies want to know how to keep their systems and data safe, and protect customers in the world of open APIs. Before they open up their APIs to third parties, they want to know how to secure data across all points of engagement.

The concern about security is well-founded. Consider some recent examples of API security risks. A top vehicle manufacturer released its APIs for climate control and battery status only to find that the authentication and authorization methodology was so weak that a hacker only needed a VIN number to gain physical control of the vehicle. Another automaker released APIs with a six-character password that was easily cracked. And the US Internal Revenue Service found out that because the password-reset mechanism for its Get Transcript application did not have a proper authentication and OAuth (Open Standard for secured delegated access) mechanism, it was easy to steal taxpayer data.

As these examples show, every point of contact is a potential point of entry for a hacker or criminal, and any breach could cost a company dearly in lost intellectual property, damaged consumer reputation, and tarnished brands. Consumers may want the smooth user experiences that open APIs can make possible, but they won’t forgive companies that expose their personally identifiable information. Breaches can also have direct costs if the company has to migrate systems and data to protect them from further attack.

What should companies do to secure APIs? I advise following four best practices. I consider these merely table stakes, but they will provide a good foundation for API security.

  1. Authentication and authorization. Use at least a two-factor authentication process to validate API users and enable you to trace anyone who gains access and interacts with your APIs.
  2. Monitoring. As part of your security strategy, you should monitor API activity to get an early indication of possible trouble. Pattern-recognition programs in API security gateways can flag unexpected calls or a sudden inflow of API calls from unusual places, for example.
  3. Have a plan for breaches. Make sure you have a good plan in place to deal with APIs that have been compromised. The plan needs to have a clearly defined process for shutting down and securing the compromised API without affecting any of the dependent applications, as well as a mechanism for notifying API users of an alternate secure path. There should also be a follow-up procedure to make sure lessons from any breach are applied to APIs across the organization.
  4. Protect the business logic. Perform thorough penetration testing to ensure that the business logic—the link between a user interface and your databases—cannot be manipulated or combined in a way that reveals data.

As noted, these best practices are just table stakes. There are growing threats to APIs that will require additional actions, which companies need to be aware of. For example, companies around the world need to continue to find ways to defend against malicious software bots, such as those used for distributed denial of service (DDoS ) attacks, which have taken down whole segments of the Internet. Similar brute force techniques can crack private APIs and compromise customer information. I often ask clients if they know whether bots are hitting their APIs and skewing their analytics, or if a competitor might be using bots to scrape price data. Usually the answer is we don’t know or we hadn’t thought about that.

Finally, there are two important don’ts: don’t overlook the risks related to APIs that are used internally, and don’t neglect proper documentation. It is essential to apply the same protections to internal APIs because the APIs that are open to the outside world often call on multiple internal APIs to seek data or deliver a response to an application. Another common error is relying on incomplete or poor documentation, which will keep developers from understanding how to use an API and learning what data and error codes will be returned.

While companies need to get smart about protecting APIs, they can also rely on vendors to help. For example, a good deal of the needed protection can be obtained by selecting the right API security gateway. As noted, an API security gateway typically will have a rate-limiting mechanism to protect against DDoS attacks. A good API gateway will also secure all points of engagement, from user interactions to the back end. And Oauth 2 authentication is a common feature to secure user and app interactions.

Srinivas Ramadath is a digital associate partner in McKinsey’s Chicago office.