Whatever type of digital system you are using, you will always need to consider API security. APIs are the glue that holds together the vast majority of modern apps and computing services. If you think of an API as the “middle man” or the communication channel which facilitates the communication between apps and servers, then it’s easy to see how precisely this point in the communication chain is one of the more attractive points for attackers to attempt to breach. Accordingly, API security, for open banking, communication apps, web applications, and practically for a company of any size needs to be an essential component of any system.
To guard against this, you need to understand what the key vulnerabilities of API systems are
What Are API Vulnerabilities?
By “vulnerabilities”, we are referring to what it is about API systems that makes them susceptible to attack. In other words, what are the weak points of any given API system? By understanding what these are, you will know what it is about the system that attracts attackers and, perhaps more importantly, at which point along the API operation chain the system is most likely to be attacked.
Main API Vulnerabilities
So what are the main API vulnerabilities? What are the weak points in the system most likely to attract attackers? Here follows the major ones, the below are only a short summary of these points, you can find a more detailed list of API vulnerabilities in API mike blog.
Broken Object Level Authorization
BOLA is one of the major API vulnerabilities that involves a very common error message that can confront everyday users of computer systems – “insufficient validation of object access request”. This occurs when an application does not correctly confirm that a particular user performing a request has the requisite clearance or privilege to access the resources of another user. This is a major point of entry for API security breaches because it allows an attacker to perform unauthorized actions by reusing an access token. This can then expose sensitive information, which can be potentially disastrous.
One of the recent examples of a malicious BOLA attack came when a French based company that goes by the name Ledger, they manufacture physical crypto wallets (Actually even I have one of these).
Ledger allowed Shopify to access their API and were maliciously attacked manipulating BOLA that used unauthorized access via third party API key to access records of customers.
The amount of customers who got their information leaked 292,000 and around 1,000,000 emails were exposed.
Broken User Authentication
As the name suggests, broken user authentication allows hackers to impersonate legitimate users. Obviously, if they can manage to do this then they can access everything normally only privy to such users, which can naturally be a major cyber security disaster, depending on what users they actually impersonate. Normally this is carried out by means of credential stuffing on the part of automated bots. All they need to do is locate a login API suffering from broken user authentication. This is the precise point in the API operation chain which is targeted. The question then arises – how does the attacker know that this username password input point is suffering from broken user authentication? Well, if an attacker inputs a username/password combo as [email protected]/ + a password, and then the system responds with “invalid password”; the attacker then knows that the username (if not the password) is indeed valid. Then they are almost halfway there.
One example of Broken user authentication in API attack was done on Trump’s town square site that goes by the name of Parler.
parler’s user authentication was for the least broken and at least one endpoint didn’t require authentication which led to access to users posts, images and videos.
Excessive Data Exposure
A mature system often has many API endpoints, these endpoints are left open as the system grows older and usually are forgotten about when developers come and go and staff changes rapidly.
Moreover these APIs hold functionally and data that are open and accessible. In general APIs should only include the functionality and data required for their intended purpose and nothing more.
Exposing too much data about existing or future products or any other information is counterproductive as it enables hackers to use the APIs to perform reconnaissance on them, which could result in stolen IP, stolen information, lost revenue, and mostly damaged reputation.
A few years ago an Indian based scooter ride share service named Bounce Share had a potential breach through their API. A researcher found that by passing a phone number a response with an access token and an ID would be sent back, this open Bounce Share API to malicious attacks when an automated process would be able to login to user accounts and gain access to information.
In conclusion
All these vulnerabilities suggest a solution that can be carried out by an API security expert. The problem is not that these vulnerabilities are difficult to fix, but that they are not always or immediately identified. Consequently, knowing what they are is the most important first step.
