APIs: Get to know them so you can secure them
APIs—application programming interfaces—are invisible to users. They work in the background. But they are critical to the functioning of your apps, and they could be dangerous if they aren’t secure.
Ask average people on the street what they think of the APIs that their mobile apps depend on, and you’ll likely get blank stares.
No surprise there. Most people don’t care much about the details of how an app works. They just want it to work. If it promises to give them directions to a new restaurant or find them a cheap flight, they don’t care what happens in the “background” to deliver on that promise.
Just like most of us don’t think about the technology that goes into making the brakes in our cars work. We see and use the brake pedal, but don’t have to see the rest of the system. We trust that the company that made the brakes spent the time and money needed to sweat the safety details.
That’s not an exact parallel to the API (application programming interface). But the principle is similar. APIs aren’t visible to the user. They are part of the back end of an app, which delivers what is visible on the front end. They allow apps to communicate directly with other programs and to send and receive data and other content to and from users. They enable the free flow of information.
APIs are one of the reasons mobile apps can do so many things so seamlessly. It is also why they are so popular. A survey by One Poll found that organizations manage an average of 363 different APIs, with 69% of companies making those APIs accessible not just to their partners but to the public as well.
But … the downside
But yes, there is a downside. As is the case with the software used to build and run applications, APIs are yet another component of the almost limitless “attack surface” of the online world. Misconfigured or otherwise vulnerable APIs can amount to the digital version of unlocked doors or broken windows, making just about every “room” in the house available.
One high-profile example, reported first in late 2018 by security blogger Brian Krebs, was that the U.S. Postal Service had allowed an API weakness that exposed account details for about 60 million users to go unpatched for more than a year after it had been notified about it by a security researcher.
Which illustrates why somebody should care about APIs: The companies that build, run and manage the millions of apps now in use. They need to sweat the security details so that they, along with their customers and users can trust that their data, personal information, money or identity won’t get stolen through vulnerabilities that hackers can exploit.
APIs aren’t new — they’ve been around for decades. But their use has evolved dramatically, as Michael Borohovski, director of software engineering at Synopsys, explains.
“Originally, an API was something developers would provide that allowed outside parties to develop functionality for that application that it didn’t already have,” he said.
“As the internet grew, however, the meaning of the term changed to mean the use of third-party web services and sites or extensions; you weren’t developing functionality for the third-party service, but rather using it to extend the functionality of whatever you were building.”
Even more recently, “API” has come to describe a sort of “contract” between a server and a client. “If a client makes a request in some pre-agreed specified format, the server will respond in some pre-agreed specified format, or take some pre-agreed action,” Borohovski said.
Attractive targets, coming and going
So, as APIs have become more ubiquitous — the ProgrammableWeb directory is closing in on 23,000 of them available for mobile and web apps, with more being added all the time — they are an increasingly attractive target for hackers.
Also, while APIs are no weaker than any other component of applications, since most were originally designed to support functionality internally, they were protected by “upstream” security controls. But when they are exposed to the public, those protections no longer help.
And attackers of APIs can get you coming and going, so to speak.
As Phil Odence, senior director of professional services at Synopsys, puts it, there are “two sides” to the API security problem. One is with internal, proprietary APIs that a company creates.
The front-end and back-end developers agree on a “syntax” and can modify, add or subtract functions as long as they use that syntax.
“But if I publish that API to the world, along with the syntax, a bad guy might be able to figure out how to use the API syntax to do something bad to my computer. He could pass me something that looks legitimate, but is malware,” Odence said. “So I’m exposed through my API.”
The other side of the problem is external. As noted, there are now tens of thousands of APIs out there, available for anyone to use. Developers love to use them because it is much easier and faster to assemble code components than it is to write them. Instead of having to write all the code necessary to build a particular function, they can simply have the app “call out” to an API somebody else has already built.
“They just write a couple of lines of code to call out to one that’s available to do a certain thing,” Odence said.
But while developers who are building an app clearly know what APIs they intend to call, Odence said most don’t keep a list of them, which means most companies don’t have an inventory of all the APIs they are using.
“Sure, a developer knows at the time what APIs he’s including,” Odence said, “but then that guy goes to another company. And most haven’t told their managers (which APIs an app is using).”
That is, in part, because developers are under pressure to deliver apps quickly, with features that will attract users. Security becomes the proverbial afterthought.
Going blind to the risk
“Developers don’t get paid to keep logs or inventories of API calls,” Borohovski said. “They get paid to ship features. So they do just that, incur technical debt and move faster than they should sometimes, always promising themselves ‘I’ll document this later.’ We all fall into this trap.”
But the reality is that apps call out to tens of thousands of possible external web services.
Which creates a number of security risks — one of them the same that exists when developers don’t keep track of open source software components they use to build apps: You can’t secure what you don’t know you’re using.
It is possible, Odence said, that an API could be “passing users’ data out and you don’t know if it’s encrypted.” Or it may have any number of other vulnerabilities or defects that could create security risks.
Those risks again come down to “coming and going.” Data that an API sends can leak, or hackers can eavesdrop on it. Data coming in can be malicious in multiple ways — it can contain executables, tampered images, viruses, or malicious code. And data going in either direction can be vulnerable to man-in-the-middle attacks, which are meant to spoof servers and obtain sensitive information, which is especially easy to do if data are unencrypted.
Beyond that are legal risks. APIs have terms of service (ToS) agreements that control what users can or can’t do with them, and whether there might be a price involved.
“Maybe you have to pay if you use it more than a certain amount, or the owner has the right to share any data you send to it,” Odence said, adding that an API owner may change the ToS at any time, and any organization that continues to use the API is “agreeing” to those new terms.
And then there are operational risks: An API can be shut down without notice, which could be devastating if the result is that your popular app stops working.
You are not hopeless, or helpless
That’s a considerable amount of bad news, or at least potentially bad news. The good news is that there are tools and services available to help organizations address those risks, both to create an inventory of what external APIs they use and to find and fix security vulnerabilities in the APIs they create.
With proprietary APIs, Borohovski said the first step is to “document it.”
“Use some standard format, typically Swagger/OpenAPI, as a living document. Treat it as the ‘truth’ and design specification for what it is you want to build. It should specify the endpoints, parameters, constraints/patterns on those parameters, etc.
“Then use an API scanner to scan it dynamically for vulnerabilities and correctness, or other static analysis tools to verify and validate the specification,” he said.
Among the most important security measures for APIs should be access controls, something that ARA (architecture risk analysis) can help address.
APIs should enforce both authentication (Who are you?) and authorization (Should you have access to this?) for every request.
For external APIs, obviously you need to find out what your apps are calling. A web services and API audit is what it sounds like — it helps create that list of web services and APIs you’re using that your developers didn’t create.
A good audit provider will scan the code in an app to generate a list of the external web services the app uses. It will also call out web services that may introduce legal or privacy risk into your application.
Borohovski also recommends that before using an external API, do some research and ask the owners what they do for security. “If the answer is ‘nothing’ or ‘we cross our fingers’ or ‘we have a checklist,’ consider using something else. There should be a process in place, they should be documenting their API in something like Swagger/OpenAPI. And they should have some testing process in place,” he said.
“You’ll also want to ensure you’re being incredibly careful about your secrets, how you store them, etc. One of the most common risks with using APIs is simply disclosing secrets inappropriately.”
