API security warrants its own specific solution

Application programming interfaces (APIs) enable developers to quickly and easily roll-out services but they’re also equally attractive to attackers. This is because they can provide ready access to back-end systems and sensitive data sets. What makes these attacks so interesting is how they are executed: unlike a traditional “hack,” an API attack doesn’t hinge on there being something wrong with the API. Rather, attackers can legitimately use the way an API functions against it and can simply find out if it hasn’t been developed securely through standard interaction.

The OWASP Foundation recognizes this fact via the API Security Top 10 list of vulnerabilities and security risks. When we look at the list, there are six common methods of execution. Three of the issues occur due to weak access control and three to business logic abuse, with the remainder existing due to insufficient traffic management, application vulnerabilities, lack of visibility and lack of operational security readiness.

These issues are unique to APIs and make them particularly challenging to secure, so let’s look at each in detail.

1. Broken object level authorisation (BOLA)

Formerly known as Insecure Direct Object References (IDOR), BOLA allows the attacker to perform an unauthorized action by reusing an access token. This method has been widely used to attack IoT devices, for instance, as it can be used to allow the attacker to access other user accounts, change settings and generally wreak havoc much to the embarrassment of the IoT vendor.

The attack relies on the API’s resource IDs or objects not having sufficient validation measures in place. In some cases, the data used by the API has no user validation and is accessible to the public, while in other cases error messages return too much information, providing the attacker with more information on how to abuse the API.

Defending against BOLA attacks requires the validation of all user privileges for all functions across the API. API authorization should be well defined in the API specification and random/unpredictable IDs. It’s also important to test these validation methods on a routine basis.

2. Broken user authentication

An attacker can impersonate a genuine user if there are flaws with user authentication. Mechanisms such as log-in, registration, and password reset can be bombarded with automated attacks and, if poorly secured, will allow weak passwords, return error messages to the user with too much information, lack token validation or have weak or non-existent encryption.

Preventing these abuses requires security to be prioritized during development. All the authentication mechanisms mentioned above need to be identified and multi-factor authentication (MFA) needs to be applied. The development team should also look to implement volumetric and account lockout protection mechanisms to prevent brute force attacks.

3. Excessive data exposure

Some published APIs expose more data than is necessary as they rely on the client app rather than back-end systems to filter. Attackers can use this information to carry out enumeration attacks and build up an understanding of what works and what doesn’t, allowing them to create a “cookbook” for stealing data or for orchestrating a large attack at a later stage.

Limiting data exposure requires the business to understand and tailor the API to user needs. The aim is to provide the minimum amount of data needed, so the API needs to be highly selective in the properties it chooses to return. Sensitive or personally identifiable information (PII) should be classified on backend systems and the API should never rely on client-side filtering.

4. Lack of resources and rate limiting

If the API doesn’t apply sufficient internal rate limiting on parameters such as response timeouts, memory, payload size, number of processes, records and requests, attackers can send multiple API requests creating a denial of service (DoS) attack. This then overwhelms back-end systems, crashing the application or driving resource costs up.

Prevention requires API resource consumption limits to be set. This means setting thresholds for the number of API calls and client notifications such as resets and lockouts. Server-side, validate the size of the response in terms of the number of records and resource consumption tolerances. Finally, define and enforce the maximum size of data the API will support on all incoming parameters and payloads using metrics such as the length of strings and number of array elements.

5. Broken function level authorization

Effectively a different spin on BOLA, this sees the attacker able to send requests to functions that they are not permitted to access. It’s effectively an escalation of privilege because access permissions are not enforced or segregated, enabling the attacker to impersonate admin, helpdesk, or a superuser and to carry out commands or access sensitive functions, paving the way for data exfiltration.

Stopping this level-hopping activity requires authentication workflow to be documented and role-based access to be enforced. This requires a strong access control mechanism that flows from “parent to child” and doesn’t permit the reverse.

6. Mass assignment

The attacker discovers modifiable parameters and server-side variables that they then exploit by creating new users with elevated privileges or by modifying existing user profiles. This can be prevented by limiting or avoiding the use of functions that bind inputs to objects or code variables. The API schema should include input data payloads and enforce segregation by whitelisting client-updatable properties and blacklisting those that should be restricted.

7. Misconfiguration

Incomplete, ad-hoc or insecure default configurations, misconfigured HTTP headers, unnecessary HTTP methods, permissive cross-origin resource sharing (CORS), and verbose error messages containing sensitive information are, unfortunately, all too common in APIs. They’re usually the result of human error, due to a lack of application hardening, poor patching practices or improper encryption and, when discovered by an attacker, can be exploited, leading to fraud and data loss.

Configuration is all about putting in place the right steps during the API lifecycle, so it is advised to implement a repeatable hardening process, a configuration review and update process, and regular assessments of the effectiveness of the settings. Defining and enforcing responses (including those for errors) can also stop information getting back to the attacker. CORS policies should also be put in place to protect browser-based deployments.

8. Injection

A staple of the OWASP Web Application top 10 list, injection attacks see the untrusted injection of code into API requests to execute commands or to gain unauthorized access to data. These attacks can happen when the database or application lacks filtering or validation of client or machine data, allowing the attacker to steal data or inject malware by sending queries and commands direct to the database or application.

The mitigation of injection attacks requires separation between data/commands and queries. Data types and parameter patterns should be identified, and the number of records returned should be limited. All the data from clients and external integrated systems should be validated, tested, and filtered.

9. Improper asset management

Poorly secured APIs such as shadow, deprecated, or end-of-life APIs are highly susceptible to attack. Other threat vectors include pre-production APIs that may have been inadvertently exposed to the public, or a lack of API documentation that has led to an exposed flaw, such as authentication, errors, redirects, rate limiting, etc.

Here it’s critical to look at the API publication process by replacing or updating risk analyses as new APIs are released. Continuous monitoring of the entire API environment, from dev to test, stage and production, including services and data flow is also advised. Adopting an OpenAPI specification can help simplify the process.

10. Insufficient logging and monitoring

Attackers can evade detection entirely if API activity isn’t logged and monitored. Examples of insufficient logging and monitoring include misconfigured API logging levels, messages lacking detail, log integrity not being guaranteed, and APIs being published outside of existing logging and monitoring infrastructure.

Logging and monitoring need to capture enough detail to uncover malicious activity, so it should report on failed authentication attempts, denied access, and input validation errors. A log format should be used that is compatible with standard security tools and API log data should be treated as sensitive whether in transit or at rest.

Unique challenges

All ten attack methods reveal how difficult it can be to secure APIs, which are continuously being spun-up, updated or replaced, sometimes daily. In fact, they’re so numerous that their security can only be enforced using automation. Consequently, many organizations have tried to use rules-based security solutions and code-scanning tools, although these are not equipped to spot the types of abuses identified in the OWASP list. Web application firewalls (WAFs), for instance, offer limited protection because they look for known threats, while an API gateway can create more problems by acting as a single point of failure.

It’s for these reasons that Gartner recently created a distinct API security category, separate from these other tools, in acknowledgement of the fact that APIs have their own set of problems (that are also often unique to the business itself).

In the “Advance your Platform-as-a-Service Security” report, analyst Richard Bartley reveals API security tooling for API discovery and protection should be regarded as having equal importance to and sit between internet edge security (i.e., WAF) and the data plane security layers (i.e., the Cloud Workload Protection Platform or CWPP). This new breed of API security is therefore cloud-native and behavior-based, allowing it to spot and respond to API-specific anomalous activity.

These new tools specifically focus on the prevention of automated attacks against public-facing applications and the persistence of API coding errors. They use machine learning to analyze APIs and web applications coupled with behavioral analysis to determine whether the intent behind API interaction is malicious or benign. They can also act by blocking, rate limiting, geo-fencing and even deceiving attackers, thereby buying time to respond. Such capabilities mean that API-specific security solutions can be applied to aid the developer and to monitor the security of the API throughout its entire lifecycle, thereby preventing the automated attacks and vulnerability exploits identified in the OWASP API Security Top 10.

With APIs continuing to outstrip web apps in the rollout of new services, we must attend to how these are secured or risk building these services on shaky foundations. The hope is that with the OWASP Project highlighting how APIs can be exploited and Gartner creating a distinct new category, the tech sector will finally realize that API security is an anomaly that merits its own solution.