An application programming interface, or API, is a piece of software that contains the programming instructions, standards and protocols that enable two applications to talk to each other.
It essentially serves as a bridge that allows data to flow back and forth between the two systems.
APIs can build these bridges in several settings, according to Randy Heffner, vice president and principal analyst serving application development and delivery professionals at Forrester Research Inc.
Open (or public) APIs are those publicly available for developers to access. Others are restricted, open only between organizations that have a business relationship (either an existing established one or a new one specifically enabled because of the API). Organizations also have private APIs, which are used to connect internal applications. Some organizations also use APIs as products, enabling services that would otherwise be impossible to deliver.
Given this range of uses, Heffner says businesses are building more and more APIs to connect both internal applications as well as connect their own internal applications with those belonging to business partners, vendors and consumers.
They’re opting to use APIs rather than more traditional integration processes, such as customized software and architecture, to bridge systems because APIs offer a speed and agility that more conventional approaches don’t – while also ensuring a secure passage for the data.
That’s the goal, at least.
“The hope is that when we design APIs, and design them well, we can speed the integration time because you have less code to write and you don’t have to know how the two systems work,” says James Higginbotham, founder and CEO of the technology consulting firm LaunchAny.
Not a perfect solution
Like other pieces within the enterprise IT stack, APIs can open organizations and their stakeholders up to risks when they’re not well designed and appropriately managed.
“APIs have reached a place where, very broadly speaking, they’re a recognized business driver and not just a technology aspect. [As a result,] we are seeing APIs handling essentially everything,” says Uri Sarid, CTO of application networks provider MuleSoft. “APIs move the needle on the business and that has swept away, ‘Should we use them? Is it Ok? And what data should we expose? to ‘What is the right way to secure them?’"
“But the real issue isn’t just how to secure one API; it’s how do you have an organizational culture that ensures all of its APIs have the appropriate level of security.”
That’s an important question, because poor API design and management can create vulnerabilities for data and systems security. Experts say that a faulty API can expose more data than it should to users who are authorized to access some, but not all, the information housed on the application serviced by the API. A faulty API also can become a weak spot that hackers exploit to steal data or attack the organization’s IT infrastructure.
It has been happening, Higginbotham says. He points to 2014 reports of a faulty Tinder API that could be hacked to show a user’s exact location and a 2015 IRS data breach enabled by a problematic agency API.
The problem isn’t with APIs as a technology, however, says Amir Herzberg, a professor and chairperson of the Comcast Center of Excellence for Security Innovation at the University of Connecticut. Rather, it’s the fault of poor human design.
He says these flaws arise from rushed production as developers race to meet tight deadlines. They also stem from programmers’ lack of understanding about the systems that the APIs expose. And they sometimes arise from programmers’ use of library code, that is, inserting established modules into the APIs they're writing for the sake of efficiency without always verifying whether these bits of code provide the needed level of security or whether they could actually even introduce a security threat.
“There are risks when you use APIs, but it’s not because you’re using APIs. The problem isn’t in the concept of them,” Herzberg says.
He says APIs are in fact less problematic than traditional integration methods and, when designed properly, can actually increase an organization’s security posture.
But that means organizations must be committed to delivering well-designed APIs.
“APIs should be designed well for security,” he adds. “You can have APIs that can minimize the risk of making mistakes and minimize vulnerabilities, and they could even enforce security.”
API security measures
To get those results, Herzberg, other security leaders and API experts advise that organizations strengthen the protocols they use to build and manage APIs.
To do that, organizations need to consider using authentication and encryption to protect any sensitive data traveling between applications via APIs.
Similarly, Sarid recommends access, identity and event management capabilities to provide organizations further visibility into what’s happening with its APIs and any possible anomalies such as access attempts asking for the usual data sets.
As Heffner says: “The first layer of defense is good network security infrastructure, that’s for everything, including APIs. And within APIs there are simpler kinds of strategy that would have some kind of impact: user name password, some credentials more than an API key, maybe a digital signature.”
Sarid says organizations can go even further by using rate limiting and throttling. He acknowledges that these aren’t necessarily considered security measures but says they nonetheless do help better secure APIs by establishing additional controls over access.
Likewise, Heffner says CIOs would be well served to articulate the rules around who can use APIs and how and when that use should occur.
“This has to do with how you handle sign-up to use APIs or the onboarding process with partners,” he says, noting that the different categories of APIs require varying levels of protection. “There could be some elements around how you’re using a user community – how easy do you make it, say, with a B2B API. There, the relationship is with the business and they have developers, but with open APIs, the individual is the user. So how does that business' partners manage which business employee can program against the API and what kind of control do you give to your customers.”
Managing API access is difficult, however, because of the volume of traffic it generates. That volume makes it hard to identify what activity is potentially malicious. “You may have tens of thousands of connections happening simultaneously on dozens and dozens of APIs [originating from] different end user devices—mobile and desktop—and different apps. You’re looking for a needle in the haystack,” says Bernard Harguindeguy, founder of Elastic Beam and senior vice president, intelligence, at Ping Identity.
Even if you do spot something suspicious, you might not be able to tie the activity to the individual or device where it originated. Authorized use of an API is typically granted through the use of tokens. “The identity of the token might be compromised or a known good actor becomes a bad actor,” says Andre Durand, CEO of Ping. “There’s no one watching the henhouse once the user is in with that identity token.”
Now, tools are emerging to analyze that traffic and more easily identify threats. Earlier this year, Ping acquired Elastic Beam, combining Ping’s ability to identify API token owners with Elastic Beam's API traffic monitoring capabilities in a product called PingIntelligence for APIs. It uses machine learning and artificial intelligence (AI) to identify patterns in user behavior and activity that might be malicious, and to assess the risk of known identified users. The tool provides the ability to block the activity or ask for further authentication or identification.
Other measures include using an API management layer, says Higginbotham. This will allow organizations to enforce access to APIs, so they can, for example, better detect malicious attacks and prevent access until proper approvals are completed.
Security experts say leading IT organizations don’t stop there. They consider not just security layers on top of the APIs but also how the APIs themselves are built, following an application development best practice that calls for baking security right into the software itself rather that treating it as an afterthought.
To that end, organizations need to be thoughtful about the code going into APIs, Herzberg says.
Because programmers have a propensity for using existing bits of code as they build new applications, including APIs, they don’t always know the origins or security posture. Given that, CIOs might be tempted to prohibit the practice. But Herzberg cautions against that, as programmers would likely find ways around an outright ban.
“You have to be reasonable about it. That means you have to have some mechanism for approving the modules of code [your organization] uses,” he says.
Formal API programs
Although such steps help strengthen API security, experts say IT leaders shouldn’t simply implement them piecemeal.
Instead, they should consider, in collaboration with their business partners, how APIs fit into the organization’s strategic plans, when and how they should be used, the kind of data that they handle and the security needs around those transactions based on business benefits and risks.
“You really need an overall approach to APIs, not a one-off kind of thing, that says, ‘This is how we secure APIs,’” Sarid says.
A formal API program ties all the elements together by establishing clear processes on how APIs are to be designed, how they’re deployed, what data they’ll expose for what purposes, and how they’ll be reviewed from a security perspective to ensure they’re strengthening, rather than jeopardizing, organizational security.
“The [companies] I see with robust API programs have a process in place that show that the APIs produced are following those rules and regulations and they go through a security review; it might be a light touch but it’s enough to look at what data it’s exposing, who’s asking for it, how it’s going to be used, and what regulations might be there,” Higginbotham says.
Moreover, a formal API program does more than ensure security, experts say; it strengthens API alignment to business goals.
As Higginbotham explains, CIOs who have a strong API program are forced to be clear on where and why APIs are needed and what systems are connected to ensure what flow of data; that insight helps the CIOs and their business colleagues to see APIs for that they are: tools that can be leveraged to achieve organizational objectives, whether those goals are speed to market or seizing new opportunities.
“It has to be thought of as a business concern as well as a technical concern. Otherwise we’ll just have a bunch of accidental APIs that put your business at risk,” he says.
He notes that those businesses with API programs understand that APIs aren’t merely part of the IT plumbing but rather business tools that need to be strategically applied and secured.
“Those who do it well tend to have a CEO-down initiative that says APIs are important, they represent the digital footprint of our business and all aspects of the organization need to be concerned,” he says.
Sarid agrees.
“The more thoughtful we are about API security, the more we can use APIs to move the business needle, which is what CISOs and CIOs want,” he says. “So this isn’t an exercise then in saying no. This is an exercise in how to say yes more thoughtfully.”
Related reading:
- API security leaves apps vulnerable: 5 ways to plug the leaks
- When APIs and DevOps Meet Cybersecurity
- Latest OWASP Top 10 looks at APIs, web apps