APIs are rapidly becoming one of the most important infrastructural layers of the Internet while at the same time becoming a critical component of modern day attacks. They are difficult to secure and determined hackers are extremely tenacious in finding ways to exploit them. Despite what some people — even experts — would lead you to believe, there are no silver bullets. That said, when proactively managed and secured, the efficacy of APIs greatly outweighs the risks associated with deploying them.
APIs are gaining a reputation for becoming a wonder drug of the type that the Web was in the mid-90’s.
Back in the mid-90s, as the World Wide Web caught-on — thanks in a large part to the tech and mainstream media — as means for businesses to very cost-efficiently communicate with their customers, it wasn’t long before every business was racing to attach one or more Web sites to the Web. Soon, it was inconceivable that a business could exist without also hanging its shingle on the Web. Today, APIs are the new Web. And thanks to the way the tech and mainstream media are painting a picture of APIs as the new must-have in order to not only conduct, but to reinvent business for participation in the new economy, businesses are once again racing to put API technology into production (and rightfully so in a great many cases). As the virtues of APIs are extolled in business media such as Forbes and Fortune, CEOs are scrambling their IT teams to beat the competition to the API-punch.
The realities of API security
While there is no shortage of information about this API gold rush that’s not to be missed, there is a distinct lack of information about the security and privacy risks that go with APIs and the degree to which a so-called “rush-job” could endanger the same digital assets that the API was meant to leverage.
Every digital technology that the human race has found to be both promising and useful has also come with its risks. No such technology has proven to be infallible. But we, as people, very often come to the conclusion that the efficacy of the technology greatly outweighs the risks associated with using it. This is the case with APIs.
As thousands of companies rush to put their APIs on the Web, very few if any fully appreciate the difficulty in securing them. In other words, the widely-perceived state of API security reflects a belief that if you rely on well-known Internet, Web, and API security standards to provision your API, then your API will be secure. However, in practice, this dangerous assumption has not borne out to be true and here are some reasons and real-world examples why.
Perceived and actual security concerns for APIs
Since 2014, many of the biggest Internet companies on the planet — the ones with nearly unlimited financial resources to devote to API security (in other words, they can employ the very best experts) — have either fallen prey to, or discovered a major API vulnerability in their API(s). This includes companies like Google, Apple, and Facebook. Security oversights and/or an API design flaws were major contributors to all of the vulnerabilities. In other words, “human error.”
This begs a very important question: If these companies, with the deepest pockets to employ the best experts, are experiencing challenges in securing their APIs, how can less resourced organizations be expected to do the same? This question matters mostly when API security is a forethought, long before anyone sits down to design an API. In a great many cases, API security is an afterthought.
When mobile applications are in use — which involves a great many API cases — the majority of the API secrets that are (a) shared between the mobile application and the API and (b) presumed necessary to secure the API and any communications with it, are easily discoverable even when standard security technologies like HTTPS are thought to have secured those communications. Not only are there are a variety of methods to expose these secrets, there are a variety freely downloadable tools — even ones that we can download to our smartphones — that require almost no expertise to operate.
One of the most promising aspects of APIs is how they scale. APIs make it possible for one application to repeat its instructions to another application with extraordinary speed. As such, APIs are ready made for hackers looking to do a lot of damage in a short period of time; which is invariably their M.O. The pupils in hackers’ eyes swell at the sight of potentially exploitable APIs.
Depending on the importance of the objective, most successful real-world API exploits involved a very multi-dimensional attack that is very difficult to defend against. For example, in October 2014, when hackers stole the security tokens (known as Oauth tokens) that it made it possible for them to impersonate thousands of Twitter and Facebook users, the attack involved phishing attacks on two separate companies, the unauthorized access of a Github source code repository, the penetration and subsequent “screen-scraping” of a customer support application, and then finally thousands of unauthorized Twitter and Facebook posts (whose links very likely infected users who clicked them with malware). The damage was done before any of the involved parties knew what hit them. In other words, the juicier the carrot, the more sophisticated the series of orchestrated exploits to get to it. Hackers will literally stop at nothing and are usually doing this while multiple vulnerabilities are left unguarded.
API security, like many forms of security, is a cat and mouse game. Just when you think you’ve got a security scheme that will keep the bad guys out, they find another way in (which invariably sends everyone back to the drawing board to close that loophole). Case in point? In the aforementioned October 2014 attack, the hackers gained unauthorized access to Oauth tokens that in turn allowed them to impersonate the end users that those tokens represented. The Internet Engineering Task Force (IETF) moved quickly to ratify the necessary security standards that will require a program to prove that it has the right to use an Oauth token on behalf of some user. This is called “proof of possession” or “POP.” Had this standard been baked into commonly used API software configurations prior to October 2014, it might have prevented the aforementioned attack. This issue also speaks to the lag time between the ratification of new security standards and the time it takes for those standards to take root in the solutions that API providers use to manage and secure their APIs.
3 key ways leaders should secure their enterprises
With Google, Apple, and Facebook all making the news recently for their security failures, CIOs and CISOs are under tremendous pressure to keep their business secure — without slowing the business down.
#1: Attack prevention
Restrict access based on client IP addresses with drag and drop filters to guard your system from bad actors and prevent replay attacks using easily configurable message expiry policies. Apply cyclic redundancy checks (CRC) to detect message tampering.
#2: Encryption, digital signatures
Maintain data integrity and confidentiality by encrypting all or part of confidential message payloads or storing access credentials in an encrypted vault. Preserve data integrity with digital signatures using newer standards like JWT and JWE. Ensure that any and all user specific data — especially OAuth tokens — are encrypted at rest.
#3: Identity management
Protect access to APIs and service endpoints by moving beyond usernames and passwords. Leverage proven security standards such as SAML, and OAuth2 or use existing LDAP stores for authentication and authorization. With API Manager, policies can be configured and applied at runtime.
Enterprise APIs must be secured by design
While there are a great many ways and known best practices for securing APIs, incorporating security by design into applications and services is crucial for the enterprise. One way companies are addressing this is through application networks, which enable security to be baked into every layer of the enterprise system.
MuleSoft’s Anypoint Platform is a complete solution for API-led connectivity that creates a seamless application network of apps, data, and devices, both on-premises and in the cloud. Find out how an application network enables enterprise security to be baked into every system efficiently and easily.
This blog post was originally published on ProgrammableWeb as part of a series on Understanding the Realities of API Security. It was modified on October 23, 2018 to account for current events. To read the full series visit ProgrammableWeb.
