The Open Web Application Security Project (OWASP) works to improve the security of software worldwide. OWASP’s well-known Top 10 lists increase awareness about the most critical security risks to web applications.
As the foundation for today’s app-driven economy, APIs have risen to the very top of those risks. API usage has exploded and has become ubiquitous across both external-facing and internal applications. To understand and mitigate unique API vulnerabilities and the growing threats against them, OWASP published its inaugural OWASP API Security Top 10.
The list provides companies with a good starting point for learning about the common weaknesses and security flaws that can exist within APIs. Of these, the most common are:
- BOLA (Broken Object Level Authorisation)
- Broken User Authentication
- Excessive Data Exposure
- Security Misconfiguration
BOLA
Accounting for about 40% of all API attacks, broken object level authorisation – or BOLA – represents the most prevalent API threat. Attackers can easily exploit API endpoints that are vulnerable to BOLA by manipulating the ID of an object sent within an API request. Because the server component typically does not fully track the client’s state, these vulnerabilities are extremely common in API-based applications.
BOLA authorization flaws can lead to data exfiltration as well as unauthorised viewing, modification, or destruction of data. BOLA can also lead to full account takeover (ATO).
Automatic static or dynamic testing cannot easily detect BOLA authorisation flaws. Traditional security controls, such as WAFs and API gateways, also miss these types of attacks because they cannot understand API context and so cannot baseline normal API behaviour.
Broken User Authentication
Broken user authentication allows attackers to use stolen authentication tokens, credential stuffing, and brute-force attacks to gain unauthorised access to applications. Attackers can take over user accounts, gain unauthorised access to another user’s data, and make unauthorised transactions. Authentication mechanisms present an easy target for attackers, particularly if they are fully exposed or public.
Technical factors that can lead to broken authentication in APIs include, among others, weak password complexity, missing account lockout thresholds, excessively long durations for password/certificate rotations, or use of API keys as the only authentication material.
Because traditional security controls lack the ability to track attack traffic over time, they cannot decipher the different forms of advanced attacks that target authentication.
Excessive Data Exposure
APIs often send more information than is needed in an API response and leave it up to the client application to filter the data. However, relying on client-side code to filter sensitive data causes problems, as attackers regularly bypass client-side web and mobile application code and call APIs directly.
In the case of excessive data exposure, attackers hope that the API will provide more information than needed – ideally, information that they can use in more complex attacks. For example, an API request for user information might also produce the admin’s user name, multifactor authentication status, and other data that is completely unnecessary to the original request.
Traditional security scanning and runtime detection tools will sometimes alert on this type of vulnerability, but they are unable to differentiate between legitimate data returned from the API and sensitive data that should not be returned.
Security Misconfiguration
Many security misconfigurations exist that often negatively impact API security as a whole and can inadvertently introduce vulnerabilities. Security misconfigurations can include insecure default configurations, incomplete configurations, misconfigured HTTP headers, verbose error messages, open cloud storage, and more.
Misconfigurations enable attackers to gain knowledge of the application and API components during their reconnaissance phase. Attackers can also exploit misconfigurations to pivot their attacks against APIs.
Defending Against API Attacks Requires Context
By their nature, APIs expose application logic. Hackers do lots of experimentation to try to identify gaps in that business logic that they can exploit. The reconnaissance needed to propagate attacks like these take a lot of time. A single API attack can take hours, days, or even weeks to unfold.
To defend against them, organizations must analyse large amounts of API traffic and API activity over time. Spotting abuses, such as BOLA, requires continuous monitoring of millions of API calls and users. Large-scale data analysis, in near real time, is essential to establish a baseline of typical API activity and the anomalies that don’t align – this is the kind of context teams need to spot API abuses.
Differentiating between legitimate requests and requests that lack proper authentication or authorization also requires rich context. Organizations need to analyse all API activity to identify attempts to exfiltrate too much data or gain access to unauthorised private data.
Server- or VM-based API security approaches simply don’t have a broad enough data set over time to identify today’s sophisticated API attacks. Only cloud-scale big data combined with AI and ML can collect, store, and quickly analyse hundreds of attributes across millions of users and API calls and correlate them. Cloud-scale big data provides the breadth and depth of context that organisations need to protect their APIs.
