Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

10:00 AM
Erez Yalon
Erez Yalon
Connect Directly
E-Mail vvv

Why You Need to Think About API Security

Businesses of all sorts are increasingly relying on APIs to interact with customers in smartphone apps, but they have their own unique set of vulnerabilities.

As cyberattackers continue to take advantage of vulnerable people, processes, and technology, they are also expanding their operations beyond the usual targets. Nothing appears to be outside of their jurisdiction, and no one is 100% safe from their malicious campaigns. Although organizations are making progress in protecting themselves, as soon as one attack vector is thwarted, another quickly becomes exposed.

Today's adversaries are focusing on APIs in particular, which are quickly becoming the new attack frontier. Recent reports suggest that by 2022, API abuses will be the vector most responsible for data breaches within enterprise web applications. This is primarily due to the extensive growth of API implementations worldwide, providing a new target that hasn't been widely exploited yet. With this, protecting APIs is becoming more important.

Although the concepts of API security are somewhat new, the attacks that can be performed through them are not. Most organizations have been experiencing similar threats targeting their networks and Internet-facing applications for years. Now, they must focus their efforts on mobile apps, APIs, and back-end servers being targeted by similar methods as seen in the past. Before discussing the risks associated with today's APIs, we must first understand exactly what makes them unique and vulnerable.

API-Based Apps vs. Traditional Apps
API-based apps are significantly different from traditional applications. In the past, users/visitors would access a web server via a browser, for example, and most of the "data processing" was performed on the server itself. As client devices became more varied and increasingly powerful — with faster CPUs, extensive memory, more bandwidth, etc. — much of the logic moved away from being performed on back-end servers to the front end (that is, on the client device itself) as highlighted in the graphic below.

In the modern application at the bottom of this graphic, the downstream server acts more like a proxy for the data consumed by the API-based app. The rendering component in this instance is the client that consumes the raw data, not the server itself.

Many will remember the early days of using smartphones and traditional websites when trying to reserve a flight, for example. People would open a browser on their phone and attempt to use an airline website that was designed for a large computer monitor, not a small smartphone screen. This didn't work too well, and companies began to update their websites by making them more smartphone-friendly. Although this improved the customer experience, navigating a website and completing an airline reservation was still quite cumbersome.  

As a result, airlines, hotels, car rental companies, etc., began to develop their own mobile apps. Instead of trying to reserve a flight using a mobile-friendly version of the airline's website via a browser on their phone, people now download and install the airline's mobile app and use it exclusively when reserving flights directly from their smartphones. So, how is this different? 

When making a flight reservation using an airline mobile app, the app uses API calls that are interacting with back-end servers primarily to retrieve data about flight schedules, availability, pricing, seats, etc. The app is also interacting with the user, allowing the customer to specify travel dates, departure and arrival cities, seat selection, and purchase options. In this case, the smartphone is performing almost all of the processing load of the flight reservation within the mobile app itself, without the use of a browser. Although this has tremendously improved the flight reservation experience overall when using a smartphone, it raises the question: Are APIs just as vulnerable to cyberattacks as browser-based applications?

The Risks Associated with APIs
Unfortunately, APIs are also exposed to attacks and, at a very high level, API security issues exist, similar to their browser-based counterparts. However, since APIs expose the underlying implementation of a mobile app, and the user's state is usually maintained and monitored by the client app, plus more parameters are sent in each HTTP request (object IDs, filters, etc.), some of the security issues surrounding APIs are unique. For the most part, these issues lead to vulnerabilities that can be categorized into three areas of concern:

  • Exposing sensitive data
  • Intercepted communications
  • Launching denial-of-service (DoS) attacks against back-end servers

A Good Project with a Nobel Cause
As a result of a broadening threat landscape and the ever-increasing usage of APIs, I, along with Inon Shkedy, head of security research at Traceable.ai, have been spearheading the
OWASP API Security Top 10 Project. The project is designed to help organizations, developers, and application security teams become more aware of the risks of APIs.

Here's what makes the project important: According to the project's site, "a foundational element of innovation in today’s app-driven world is the API. From banks, retail, and transportation to IoT, autonomous vehicles, and smart cities, APIs are a critical part of modern mobile, SaaS, and web applications, and APIs can be found in customer facing, partner facing, and internal applications. By nature, APIs expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this, have increasingly become a target for attackers. Without secure APIs, rapid innovation would be impossible."

The OWASP API Security Project aims to develop, release, and track an ongoing top 10 list of the risks that organizations face concerning their use of APIs, similar to the OWASP Top 10 Most Critical Web Application Security Risks. From broken object-level authorization to insufficient logging and monitoring, this list rounds up the most critical API risks facing businesses while also providing example attack scenarios and recommendations for mitigating these threats. IT teams, security professionals, and developers alike would be well-advised to carefully read through this list to better understand the benefits of APIs, as well as the potential risks presented through their implementation as adversaries set their sights on this emerging target. 

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "The Beginner's Guide to Denial-of-Service Attacks: A Breakdown of Shutdowns."

Erez Yalon heads the security research group at Checkmarx. With vast defender and attacker experience and as an independent security researcher, he brings invaluable knowledge and skills to the table. Erez is responsible for maintaining Checkmarx's top-notch vulnerability ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Threaded  |  Newest First  |  Oldest First
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
Omdia Research Launches Page on Dark Reading
Tim Wilson, Editor in Chief, Dark Reading 7/9/2020
4 Security Tips as the July 15 Tax-Day Extension Draws Near
Shane Buckley, President & Chief Operating Officer, Gigamon,  7/10/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...