Developer, Beware: The 3 API Security Risks You Can’t Overlook
An API is more than the connective tissue that enables applications and databases to seamlessly work together. It is also a pathway for hackers to access an organization’s applications and sensitive data, often out of sight and undetectable.
A survey conducted by Forrester finds that the majority of organizations (60%) have published between 25 and 500 public APIs. Over the next year, developers will write and publish even more APIs to deliver new application capabilities and improve integrations or service delivery. Yet, development happens so quickly that too often the API is released into production before it’s reviewed closely, cataloged and assessed for security issues.
It’s time to be proactive about embedding security into the development life cycle. According to the same survey, 56% of developers say API security is a key priority for them in the coming 12 months. As the volume of security incidents caused by vulnerable or misconfigured APIs multiplies, developers need to be aware of the risks and how they work.
Below are the three big API security risks you need to be familiar with and how to protect your APIs from these attacks.
Broken Object-Level Authorization (BOLA)
Object-level authorization is an access-control mechanism implemented at the code level to validate that an authorized user can access objects that they should have permission to access.
BOLA is a complex threat where attackers identify the API endpoints used as a data source along with their specification and data patterns. Attackers exploit the API endpoint with a simple script that manipulates the data, replacing values in the API endpoint parameters to gain access to the sensitive data returned by the API. These incidents lead to data leakage and can even lead to the modification or destruction of data.
How to prevent it:
- Design and implement authorization based on user roles and policies. Build a hierarchical, role-based model that can be used by all application services.
- In complex microservices-based architecture, it is important to pass along the roles, privileges and entitlements of the authenticated user to every subsequent downstream service within your internal API calls.
- Every service must implement authorization checks prior to acting on the request within the API, especially prior to returning any data.
- In most BOLA exploits, attackers iterate through predictable sequential patterns such as a sequence of numbers. As APIs are designed and implemented, consider randomizing the input, for instance using globally unique identifiers (GUIDs) for numeric IDs.
- As APIs are implemented, incorporate specific tests targeted toward BOLA issues.
Excessive Data Exposure
By design, the majority of APIs send data from the data store to the client. Excessive data exposure results when the API has been designed to return large amounts of data to the client. Attackers can collect or harvest sensitive data from such API responses.
For example, a group fitness app displays the home location of the group’s participants. The locations are displayed on a map using the latitude and longitude of each athlete. A well-designed API is intended to return only the latitude and longitude of each athlete. Conversely, a poorly designed API returns user information about each athlete, including their full name, address, email, phone number, latitude and longitude, and more. This is an example of excessive data exposure as the API is returning more data than it was designed to do.
This might occur when a poorly designed API pulls a record from the database and returns it to the client in its entirety, exposing all the data in the file. In this situation, the true business use case was not fully understood during development.
How to prevent it:
- Consider a design philosophy to create APIs for specific use cases. This allows for the implementation of authorization controls for data in the future.
- Do not rely on clients to filter out sensitive data.
- Review all APIs to ensure their responses are returning only the intended data.
- Audit business use cases that use an existing API for excessive data exposure.
- During code review, test APIs to ensure the intended amount of data is exchanged between the data store and client.
- Avoid reading records from the data store and returning them directly as responses within the API.
- Periodically conduct an audit of your APIs and categorize them based on the nature of the sensitivity of the data flowing through it.
- If your APIs provide flexibility of supplying filters (such as GraphQL), implement a schema-based response validation.
Broken Function-Level Authorization (BFLA)
Simply put, these are incidents where a regular user can execute an administrator’s task. This results from complex, broken or incomplete access control policies. Attackers with normal or basic roles/privileges can exploit these function-level authorization issues, gaining access to other resources and/or administrative functions.
APIs with complex permissions and user roles that span the authorization hierarchy are prone to this vulnerability. This issue usually occurs at an API endpoint — which in some cases is considered to provide a function — or the method used to access the API endpoint.
For example, a normal user is viewing their employee details. On the application side, it means a GET request is made for the API endpoint, such as /api/v1/employeeDetails. An administrator can make changes to these details and is allowed to use a PUT request for the same endpoint /api/v1/employeeDetails. If the API does not implement the proper authorization at the function level, the normal user might have permission to make the PUT request and subsequently change their own employee details. Similar to BOLA, implement authorization checks when a function-level request is received from the client.
How to prevent it:
- Design and implement authorization based on user roles and policies. Build a hierarchical, role-based model that can be used by all application services.
- It’s important to pass along the roles, privileges and entitlements of the authenticated user to every subsequent downstream service within your internal API calls.
- Every service must implement authorization checks prior to acting on the request within the API. As a general rule, consider denying all access by default and grant access to specific roles.
- Review and audit APIs with multiple functions or methods to identify any authorization issues.
- Anticipate complex user roles and group hierarchy. Implement specific tests as part of your development process that emulate BFLA.
Stop API Security Risks by Implementing the Right Defenses
Addressing these complex and sophisticated API security risks begins by having a clear assessment of those risks during development and production runtime. The assessment starts with automated discovery and an up-to-date API catalog that continuously adapts to the changes in every API.
Catalog APIs by specific categories, such as APIs that transact sensitive data, APIs that return excessive data or APIs that allow normal and admin users to operate different functions. Next, apply automation and machine learning to assess API behaviors, preferably early in the development and testing stage. Evaluate this against risk-based policies and determine appropriate actions for mitigating the threats — particularly data-exchange patterns so that runtime protection can be enabled based on an always up-to-date baseline of behavior.