APIs are the backbone of numerous popular web services because of their utility, ubiquity, and increasing architectural choices. Like many technological advancements, the gain from changes includes new threats and risks. The development of REST challenged the older SOAP API, and the growth of GraphQL is challenging REST. But none has completely replaced the other – they are now all in existence, along with other API frameworks.
This complexity makes it impossible to make a convenient list of all API vulnerabilities and how to protect them. Given that, this article explores some common vulnerabilities to note. Regardless of the API architecture chosen, there are shared factors that make them all vulnerable.
Common API vulnerabilities
We’ll focus on seven common API vulnerabilities, all from the OWASP API Security Top 10. The first one presented is #1 on the OWASP API Top Ten list and received some prominent coverage because of the Peloton security incident in early 2021 (this incident actually involved a few API vulnerabilities). The other 6 are frequent attack types. I reference OWASP’s API list because it’s well-regarded, widely accepted, and freely accessible. Additionally, OWASP’s document presents scenarios and provides prevention techniques.
Below are the vulnerabilities I’m highlighting in this article.
- API1:2019 Broken Object Level Authorization
- API2:2019 Broken User Authentication
- API3:2019 Excessive Data Exposure
- API7:2019 Security Misconfiguration
- API8:2019 Injection is like A03
- API9:2019 Improper Assets Management
- API10:2019 Insufficient Logging & Monitoring
The first one, API1, affectionately known as BOLA, was part of the Peloton incident. Object level authorization verifies a user’s ability to access a given object, such as the data associated with the user’s own account. In a BOLA attack, a user authenticates using his identity and then manipulates a subsequent API call to insert a different UserID to try to pull data associated with that second user’s account. As an analogy, while only members can get into a gym, the lockers also need locks so that only the user of that locker can get to it. It does no good to restrict membership but allow members to access each other’s belongings.
API2, Broken User Authentication, addresses APIs being vulnerable to activities such as brute force attacks, credential stuffing attacks, and weak passwords. API2 also points out the difficulty in monitoring all the ways of authenticating to the API, such as deep links that use one-click authentication. Companies need to properly secure their JWTs (JSON Web Tokens) and ensure proper authentication practices.
In API3, Excessive Data Exposure, any APIs that rely on the client to filter the API responses could let an attacker sniff the response traffic to capture sensitive data. Developers should ensure that data is filtered in the serving up and not rely on client-side filtering.
Coming in fourth is Security Misconfiguration (API7). Attackers will discover entry points such as unpatched flaws and unprotected files to gain access.
Next up is Injection (API8). Attackers use scanners and fuzzers to feed malformed or malicious data into web fields – e.g., URL, contact forms – hoping that the data will be submitted instead of sanitized. If the API is vulnerable, the submitted data will make the database take action and disclose data that it shouldn’t.
API9 (Asset Management) is similar to the concept of “you can’t protect what you don’t know you have.”
Here’s an example directly from the OWASP API Security Top 10 document:
“After redesigning their applications, a local search service left an old API version (api.someservice.com/v1) running, unprotected, and with access to the user database. While targeting one of the latest released applications, an attacker found the API address (api.someservice.com/v2). Replacing v2 with v1 in the URL gave the attacker access to the old, unprotected API, exposing the personal identifiable information (PII) of over 100 Million users.”
APIs are so helpful to developing fast and sharing valuable data and services that API use is growing exponentially. This popularity has led to API sprawl – someone spins up multiple services in a hurry, those services are not tracked, they are then deprecated but not spun down…then they’re forgotten. API sprawl will lead to public-facing security holes.
Last on my list is Insufficient Logging & Monitoring (L&M). API10 is not a matter of not logging – everything logs and monitors these days. Companies need to log and monitor for relevant data. Anyone who has worked with L&M knows how hard it is to get it right. Too little L&M and nothing worthwhile is caught. Too much, and not only is there alert fatigue, but the financial expenditure spirals out of control because of the excessive data ingestion.
APIs are the backbone of numerous popular web services because of their utility, ubiquity, and increasing architectural choices. Regardless of the API architecture chosen, there are shared factors that make them all vulnerable. #cybersecurity #respectdataClick to TweetSecuring APIs
The Salt Security API Security Checklist, which contains links to other API defense resources, is a great starting point on the way to securing APIs. While your APIs may be unique, the need to secure them isn’t. There’s a wealth of gratis information online to help developers, DevOps, engineers, security teams, etc., secure their APIs, and as a result, the data of customers and coworkers.
