The 3 API Security Risks You Can’t Ignore: The New Stack

The 3 API Security Risks You Can’t Ignore: The New Stack

A api it’s more than the connective tissue that allows applications and databases to work together seamlessly. It’s also an avenue for hackers to gain access to an organization’s sensitive data and applications, often hidden and undetectable.

Ravi Balupari

Ravi is a security researcher and engineer with over 20 years of experience in cybersecurity. Balupari co-founded the Netskope engineering team and later co-founded CloudVector, which was acquired by Imperva. He was awarded 11 patents in areas like network security, cloud security, and ransomware detection. He has a master’s degree from Ohio University and a bachelor’s degree from Jawaharlal Nehru Technological University.

A survey conducted by Forrest finds that most organizations (60%) have published between 25 and 500 public APIs. Over the next year, developers will write and release even more APIs to deliver new app capabilities and improve integrations or service delivery. However, development happens so fast that all too often the API is released to production before it’s been closely reviewed, cataloged, and assessed for security issues.

It’s time to be proactive about integrating security into the development lifecycle. According to the same survey, 56% of developers say API security is a key priority for them in the next 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.

Here are the top three API security risks you should be aware of 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 the objects they want. should have permission to access.

BOLA is a complex threat where attackers identify the API endpoints used as a data source along with their specifications and data patterns. Attackers exploit the API endpoint with a simple script that manipulates the data, replacing values ​​in the API endpoint’s parameters to gain access to sensitive data returned by the API. These incidents lead to data leakage and can even lead to data modification or destruction.

How to prevent it:

  • Design and implement role-based authorization and user policies. Create a role-based hierarchical model that can be used by all application services.
  • In a complex microservice-based architecture, it is important to pass the roles, privileges, and rights of the authenticated user to each subsequent downstream service within internal API calls.
  • Every service must implement authorization checks before acting on the request within the API, especially before returning any data.
  • In most BOLA exploits, attackers iterate through predictable sequential patterns, like a sequence of numbers. As APIs are designed and implemented, consider randomizing input, for example, using Globally Unique Identifiers (GUIDs) for numeric IDs.
  • As APIs are implemented, incorporate specific tests targeting BOLA issues.

Excessive data exposure

By design, most APIs send data from the data store to the client. Excessive data exposure occurs when the API is designed to return large amounts of data to the client. Attackers can harvest or collect sensitive data from such API responses.

For example, a group fitness app shows the home location of group participants. Locations are displayed on a map using each athlete’s latitude and longitude. A well-designed API is meant to return only the latitude and longitude of each athlete. In contrast, 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 returns more data than it was designed to do.

This can happen 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 build APIs for specific use cases. This allows the implementation of authorization controls for data in the future.
  • Don’t trust clients to leak sensitive data.
  • Review all APIs to make sure your responses return only the data you expect.
  • Audit business use cases that use an existing API for excessive data exposure.
  • During code review, test the APIs to ensure that the desired amount of data is exchanged between the data store and the client.
  • Avoid reading records from the data store and returning them directly as responses within the API.
  • Periodically audit your APIs and rank them based on the sensitive nature of the data flowing through them.
  • If your APIs provide the flexibility to provide filters (such as GraphQL), implement schema-based response validation.

Broken Function Level Authorization (BFLA)

In a nutshell, these are incidents where a normal user can run an administrator task. This results from complex, broken, or incomplete access control policies. Attackers with normal or basic roles/privileges can exploit these authorization issues at the role level, 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 problem usually occurs on 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 the details of their employees. On the application side, it means that a GET request is made to the API endpoint, like /api/v1/employeeDetails. An administrator can make changes to these details and can use a PUT request to the same endpoint. /api/v1/employeeDetails. If the API does not implement proper authorization at the function level, the normal user could be allowed to make the PUT request and subsequently change the details of their own employees. Similar to BOLA, implement authorization checks when a function level request is received from the client.

How to prevent it:

  • Design and implement role-based authorization and user policies. Create a role-based hierarchical model that can be used by all application services.
  • It is important to pass the roles, privileges, and rights of the authenticated user to each subsequent service within their internal API calls.
  • Each service must implement authorization checks before acting on the request within the API. As a general rule of thumb, consider denying all access by default and granting 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 starts with having a clear assessment of those risks during the development and production runtime. Evaluation begins with automated discovery and an up-to-date API catalog that continuously adapts to changes in each API.

Catalog APIs into specific categories, such as APIs that process sensitive data, APIs that return excessive data, or APIs that allow normal users and administrators to operate different functions. Next, apply automation and machine learning to evaluate API behaviors, preferably early in the development and testing stage. Evaluate this against risk-based policies and determine appropriate actions to mitigate threats, particularly data sharing patterns so that runtime protection can be enabled based on an always up-to-date behavioral baseline.

Outstanding image via pixabay

Leave a Comment