Application Programming Interfaces, more commonly known as APIs, are the interfaces that serve as the connections between computer programs, web applications and mobile applications. We all use APIs many times a day without even realizing.
Take the weather app on your iPhone. Apple is not actually collecting weather data themselves, but instead uses an API to ‘call’ the latest weather details from a third party weather source. Another example is an online bill payment portal.
To avoid having to code an entire credit card processing application, developers call an API from a card processing service to process the payment for them in return for a percentage of the commission.
A Brief History of APIs
In the old days, legacy web applications used to process client requests, run backend logic (querying and updating databases), and generate HTML markup to be rendered on the browser.
While this approach was sufficient to launch the first generation of web based products, a new architecture was needed for managing the reading and writing of state with a growing list of different clients – Web based SPAs (rich UIs in the browser), Mobile Apps, IOT devices, etc.
So, in came Application Programming Interfaces (APIs), which decoupled the data layer of applications from the rendering layer – and opened up a whole new world of possibilities.
APIs Seeing Increased Adoption
Usage of APIs has increased dramatically in recent years. In fact, while the exact numbers may vary, most web traffic is now largely driven by APIs.
According to Cloudflare, API traffic is the highest growing type of web traffic on their global network, accounting for 55% of total requests. Akamai’s recent report even stated that as much as 83% of web traffic is now API traffic.
As the usage of APIs is becoming more and more prolific, greatly increasing attack surfaces, API Security is quickly gaining importance. When talking about API Security, it is important to first understand and know the OWASP API Security Top 10.
The OWASP® Foundation is most known for its OWASP Web Application Security Top 10, the de facto standard that outlines the most critical security concerns for web applications.
However, a few years back, OWASP felt the need to publish a list specifically dedicated to API risks, given how vulnerable APIs had become and how attackers could seek to exploit those vulnerabilities.
In this article we will explain more about API Security and its challenges, and will then take a closer look at the top 10 API security risks, as detailed by the OWASP Foundation.
What Is API Security?
The traditional client-server world of the web, in which a server runs a web app and a browser makes a request and spins up some HTML code in response, is long gone.
Today, there are multiple clients – a web application, mobile clients, and different customers who want to build their own applications, integrations and workflows – that are all consuming the web application’s APIs.
As applications are evolving faster than ever, they create and expose more APIs, greatly increasing your attack surface.
APIs are an attractive attacker target, as they retrieve information and modify information (often sensitive functions and data), which works well for business integration and innovation but comes with security risks.
API Security focuses on strategies and solutions to understand and mitigate the unique vulnerabilities and security risks that go hand in hand with using APIs.
API Security Challenges
Development teams move quickly, particularly when developing cloud-native applications, sometimes without taking time for proper documentation and other security best practices.
“The result is that companies do not know the extent of their API inventory and whether those application interfaces are secure,” says Sandy Carielli, a principal analyst with Forrester Research.
API based attacks have already increased exponentially. According to a recent report, organizations experienced a 681% increase in API attack traffic in 2021, while their overall API traffic grew 321%. In addition, 95% of respondents said they suffered some sort of API security incident in the last 12 months.
This trend only seems to be continuing, with Gartner predicting that API abuses will become the top attack vector for most companies in 2022.
OWASP API Security Top 10
The Open Web Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software. The OWASP API Security Top 10 focuses on the strategies and solutions to understand and mitigate the unique vulnerabilities and security risks of APIs.
For reference, we’ve summarized the top 10 API Security risks as specified by OWASP below:
- Broken Object Level Authorization (BOLA) – APIs often provide access to endpoints with sensitive data, including personally identifiable information (PII), by exposing object identifiers. Object identifier access can be controlled by implementing object level authorization in the API requests. However, failure to implement object level authorization enables attackers to gain unauthorized access. In addition to ensuring that user policies and hierarchy is the basis for authorization, security teams should test this authorization in every function that accesses a data source using an input from the user.
- Broken User Authentication – Unlike authorization, which focuses on permissions, roles, and access, API authentication is a critical service that performs identification checks on clients trying to access applications. In other words, it focuses on who you are. A broken authentication mechanism increases the risk that attackers are able to use stolen authentication tokens, credential stuffing, and execute brute force attacks to assume other users’ identities. Ways to lower this risk include knowing all the possible flows to authenticate to the API, identifying stale user authentication tokens, and monitoring APIs that are accessed without authentication. Multi-factor authentication (MFA) policies are always recommended as well.
- Excessive Data Exposure – It often happens that developer teams may mistakenly implement generic APIs that provide more data than is needed, relying on client applications to perform data filtering before displaying it to the user. An attacker can fairly easily extract the leaking data at scale. Attackers can then potentially carry out a breach or use the exposed data to gain elevated privileges. To reduce this risk, don’t rely on the client to filter the data returned from APIs, but rather only expose data that is actually needed by the client. In addition, security teams should work with developers to categorize APIs and parameters that contain or transact sensitive data so they can monitor them for abuse.
- Lack of Resources & Rate Limiting – This risk occurs when API developers do not place restrictions on the size of resources and the frequency of client requests. Attackers can exploit this risk through brute force, making numerous API requests to break through the authentication, thereby overwhelming the backend server and resulting in Denial of Service (DoS) and web performance issues. To prevent this, security and developer teams should monitor API call rates, the number of resources requested, and the response to them.
- Broken Function Level Authorization (BFLA) – This is different from risk #1 above that focuses on object authorization. Functions, as opposed to objects, encompass certain actions, for example, updating or deleting customer records. Or it might be an update of roles. All APIs should have a mechanism to authorize who can perform which functions. However, when this authorization is not properly implemented, attackers can gain access and execute these administrative functions in an unauthorized way. To prevent this, denying access by default, detecting behavioral anomalies, and frequent auditing of authorization logs are recommended. It is quite common that especially powerful API endpoints, such as Admin actions, are most vulnerable to BFLA.
- Mass Assignment – Some APIs persist data sent in API requests to the underlying database, without properly checking its validity. In a ‘Mass Assignment’ attempt, all users are able to input and change data due to a lack of access controls based on an allow list. For example, a customer might pay his bill on an energy provider website, and through an API, the bill would be updated as paid after the customer inputs his credit card information. But in this flaw, a customer would be able to simply update his bill as paid, even when it is not, since all users would have the right to perform this action. Malicious attackers could use mass assignment to change critical data properties – such as updating their user profile with “admin: true”, and hoping the API is naive enough to persist this change. Resulting exploits include privilege escalation, data tampering, or bypassing of security mechanisms. Security and DevOps teams should work together to ensure application code is explicit about persisting fields from requests – rather than implicit.
- Security Misconfiguration – There are many possible misconfigurations within API resources, transport protocols and application infrastructure, which are usually a result of insecure default configurations, open cloud storage, misconfigured HTTP headers, or verbose error messages containing sensitive information. Attackers can exploit these misconfigurations in many ways, including data theft and account takeover. Furthermore, it’s important to note that security misconfigurations in APIs may lead to negative chain reactions – for example a misconfiguration in CORS / CSP frame-ancestors headers would provide attackers with incentive to run phishing attacks on the exposed platform’s users/customers, in an effort to exploit the vulnerability. DevOps should be encouraged to take a shift left approach to application security, ensuring that misconfigurations are identified as early as possible in the development lifecycle.
- Injection – This is when untrusted data can be sent to an interpreter, or parsed by the application server and passed to some integrated service, as part of a command or query. Injection flaws often include SQL, NoSQL, and OS commands. Attackers can use this data to execute unauthorized commands, corrupt other data, cause denial of service, or perform other malicious actions. Preventing injection requires keeping data separate from commands and queries, as well as detecting anomalies as early as possible.
- Improper Assets Management – This mainly refers to the risk of unpatched older APIs and outdated documentation, leading to security vulnerabilities. If security teams do not have access to an API inventory, or have no retirement strategies for obsolete APIs, they have no way to prevent attackers exploiting vulnerabilities in these systems. It’s important to inventory all API hosts (including details such as OS version, who has network access, and API versions) as well as API integrated services. APIs that contain sensitive data should receive patching priority. Gaining visibility at scale into the vast API inventory is not trivial by any means, yet critical in taking down zombie / rogue API endpoints, before attackers get a hold of them.
- Insufficient Logging & Monitoring – API threats are often missed because of a lack of proper logging, monitoring, and alerting. Without logging and monitoring, or with insufficient logging and monitoring, it is almost impossible to track suspicious activities and respond to them in a timely fashion. Security teams should keep logs of failed attempts, monitor them frequently, and ensure that logs are formatted so that other tools can consume them as well. A good practice would also be to integrate data from logs into wider cloud security or SIEM platforms.
Orca Security’s Take on API Security
Orca’s agentless approach allows for wide-scale deployment – building a complete Web and API inventory in minutes, and detecting OWASP API Top 10 findings. We’re planning to write a lot more on API security in the coming months, so stay tuned.
About Orca Security
The Orca Cloud Security Platform offers agentless cloud security and compliance for AWS, Azure, and Google Cloud in a fraction of the time and operational costs of other solutions. To learn more, sign up for a free cloud risk assessment or watch a 10-minute demo.