Organizations manage 363 APIs, on average. But vulnerable APIs can expose your data to anyone who knows how to ask for it. API security starts with the basics.
The original version of this post was published in Forbes .
It’s obvious that just about every entity with an online presence thinks APIs (application programming interfaces) are pretty cool―and necessary.
A survey by One Poll found that organizations manage an average of 363 different APIs, with 69% of organizations making those APIs accessible not just to their partners but to the public as well.
For good reason. As a description in TechCrunch put it, APIs provide “critical connective tissue andincreasingly important functionality” among software components. That includes rules about how different parts of online applications such as databases and webpages should interact with one another.
Unfortunately, cyber criminals think they’re pretty cool too. Because 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.
Again TechCrunch: “APIs are an attractive target for threat actors because they act as the glue linking different services―they allow data to flow freely from one area to the next, and thus provide a rich vein of information if they are compromised.”
API attacks on the rise
Jesse Victors, security consultant at Synopsys, said he has seen multiple instances where “an API allows users to log in and authenticate themselves, but doesn’t perform any authorization checks beyond that point. As a result, someone can retrieve information belonging to another user―a privilege escalation.”
That is not a technical problem with the API itself, he said, “but rather an implementation failure to secure it against common and well-known types of attacks.”
There are an alarming number of recent examples.
Just a few weeks ago, security blogger Brian Krebs reported 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. The researcher, who wanted to remain anonymous, got so frustrated he eventually contacted Krebs.
Krebs verified the vulnerability, which he said “letany logged-in usps.com userquery the system for account details belonging to any other users, such as email address, username, user ID, account number, street address, phone number, authorized users, mailing campaign data and other information.”
Once Krebs contacted the USPS, the agency fixed the problem, saying in an emailed statement to Threatpost that “the information shared with the Postal Service allowed us to quickly mitigate this vulnerability.”
Quickly―after more than a year of ignoring it.
Unfortunately, the USPS is not alone. The list of high-profile companies that exposed information on customers due to API problems in just the last few months includes online retail giant Amazon , telecom T-Mobile , food retailer Panera Bread , and the Black Hat security conference , where an attendee hacked his own badge and demonstrated that he could access the data of everybody else who had attended, thanks to a “legacy” (i.e., leaky) API used by theBCard maker, ITN International.
RELATED: These hacks brought to you by ‘leaky’ APIs
Are APIs inherently unsecure?Does this make APIs the new “weakest link in the security chain”?
Not necessarily. Part of the problem is that there are more―a lot more―of them to secure. “As technologies shift to single-purpose microservices, we are seeing more and more APIs to facilitate that communication, and thus there are more APIs and implementation to configure and secure,” Victors said.
Andrew van der Stock, senior principal consultant at Synopsys, added, “The attack surface is greater simply because of the greater demand for B2B connectivity. The information was always there, but difficult to get at. APIs make the friction of doing business much less, so we expect to see explosive growth of APIs―the business need is just too great to stopper this genie.”
And Chris Schmidt, senior staff research engineer at Synopsys, said APIs are no weaker than any other component of application development, but have become a more popular target because many were designed to support functionality internally and were therefore protected by “upstream” security controls. But when they are exposed as public, “those controls are no longer present.”
Also, based on recent events, they are probably among the most ignored of security chain links. Nicholas Weaver, researcher at the International Computer Science Institute and lecturer atUniversity of California, Berkeley, told Krebs that implementing access controls is “not even Information Security 101, this is Information Security 1,” and that the failure of the USPS and others to do so was “catastrophically bad.”
Indeed, multiple experts have noted that APIs should enforce both authentication (Who are you?) and authorization (Should you have access to this?) for every request.
Which means that buried in all this bad news is good news: This is a problem that can be fixed, by deploying APIs correctly and with better security testing. Doing the basics, in other words.
How to prevent unsecure APIsVan der Stock said the security industry needs to “shift left”―start security testing early and continue throughout the development process.
“They need to adopt the same tooling as developers and write the sort of tests that fully exercise APIs, particularly those that have the potential to extract bulk personal information,” he said.
Victors added that engineers building an API, a protocol, or any other structure should “take the time to consider how their application handles unusual requests. A good place to start would be the 2017 OWASP Top 10 , which lists and describes the most common application risks and is based on an industry analysis of m