Kill BOLAs Before They Escape: Secure your APIs with Aptori

API security has emerged as a paramount concern for enterprises, driven by the escalating frequency of attacks seeking to exploit vulnerabilities within APIs. Surveys conducted in early 2023 indicate that 78% to 92% of organizations experienced security incidents related to APIs in the previous year. The OWASP API Security Top 10, lists Broken Object Level Authorization (BOLA) and Broken Object Property Level Authorization (BOPLA) as the most prevalent and high-risk weaknesses. 

This raises a pertinent question: In the face of a plethora of security tools deployed during development and runtime, such as SAST, SCA, DAST, API gateways, and web application firewalls (WAF), why do API security breaches persist? And what are the requirements for an effective BOLA killer?

Authorization Policy is Business Logic

Authorization policies range from coarse-grained role-based access to more fine-grained access control based on attributes of a user or resource. The implementation of the Application logic becomes increasingly complex to implement for sophisticated authorization policies, thereby elevating the likelihood of unintentional mistakes. Malicious actors exploit these flaws by using the API as an entrypoint.  Existing protection technologies predominantly focus on identifying known vulnerabilities in common third-party software. Regrettably, these tools often fall short of identifying flaws within the application business logic that is specific to an individual enterprise application.

Among the OWASP API Security Top 10, Broken Object Level Authorization (BOLA) and Broken Object Property Level Authorization (BOPLA) emerge as the most prevalent and high-risk weaknesses. The source of both weaknesses lies in the specific implementation of the resource access policy.

To mitigate the security risks, software development teams must conduct a comprehensive set of tests to verify the implementation of a given access policy.

The Complexity Of Authorization Policy Testing

The challenge of validating an authorization policy lies in the number of test cases, posing a substantial burden on teams to create and maintain the tests. Let's delve into how the volume of test cases escalates in direct relation to the complexity of an access policy.

An entity is a piece of data, usually a resource of a particular type or a field of such a resource.  For example, the Calendly API contains resource types such as Event, User, and Organization.  Instances of these resource types have unique identifiers that are used to perform an API operation on the entity.  For instance, an Event with _{ID ABC123}  may be read using _{HTTP GET} on the URI of the entity:

_{GET https://api.calendly.com/scheduled_events/ABC123}

Let's consider an authorization policy for the Event resource.

• A user that creates an Event can read, update, and delete it.
• A user with an "admin" role can read any Event.

In this example, two possible actors can create an Event: a user without an "admin" role and one with an "admin" role.  Three possible actors can attempt an action on a particular Event:

• user that created the Event
• regular user that did not create the Event
• an admin user

Thus, the number of test cases is:

_{2 creators * 3 actors * 3 actions * 1 entity type = 18 test cases}

In any given application, there may be several  entity types, and the number of API test cases for an authorization policy increases in proportion to the number of entity types (i.e., resource types).

Next, consider a single refinement of the simple authorization policy above.  The Calendly API serves multiple organizations (or tenants), each with a set of regular users and admin users.  The administrators of one organization should not be able to act upon Events belonging to a different organization.  In that case, the authorization policy changes as follows:

• A user that creates an Event can read, update, and delete it.
• A user with an "admin" role can read any Event that belongs to the user's organization.

How does this change the number of test cases?  Now, there must be test cases for 4 kinds of users that can create an Event:

• Regular user in Org1
• Admin user in Org1
• Regular user in Org2
• Admin user in Org2

Further, the number of actors that attempt an action on an Event increases from 3 to 5:

• User that created the Event
• Non-admin user in the same organization as the creator of the Event
• Admin user in the same organization as the creator of the Event
• Non-admin user in a different organization than the creator of the Event
• Admin user in a different organization than the creator of the Event

The number of test cases becomes:

_{4 creators * 5 actors * 3 actions * 1 entity type = 60 test cases}

For this single change to the authorization policy, the number of test cases increased by more than 300%.  And remember, the number of test cases increases by the number of entities.

The BOLA Killer - Autonomous Testing of Authorization Policies

Aptori's Sift, an autonomous security testing tool, can create and run test cases to verify an authorization policy. Indeed, Sift can generate and carry out API tests for simple and complex authorization policies. It ensures comprehensive testing of all possible scenarios involving creators, actors, actions, and entities, handling anything from 10 to thousands of test cases, all completed swiftly within seconds.

Imagine a product owner providing the simple authorization policy described above as a table of permissions by role.

This seemingly simple policy requires 60 test cases to fully validate the authorization policy.  Given the authorization policy and the API definition, Sift autonomously generates and executes all 60 test cases.

The authorization policy can be represented in Sift's YAML configuration as follows:

policy:
  - resources:
      - event
    owner: userOrg1
    permissions:
      - user: adminOrg1
        access: ["read"]
      - user: userOrg1
        access: ["read", "update", "delete"]
  - resources:
      - event
    owner: userOrg2
    permissions:
      - user: adminOrg2
        access: ["read"]
      - user: userOrg2
        access: ["read", "update", "delete"]

Exactly! With this uncomplicated policy approach, sift generates 60 test cases, thoroughly assessing each authorization scenario to confirm the security of your API and its immunity to BOLA risks.

Conclusion

Development teams often grapple with the challenge of balancing their resources between thorough testing and advancing feature development, especially under tight project deadlines. To ensure the delivery of secure applications, it's crucial for teams to conduct dynamic, end-to-end testing on the running application. This approach is key in addressing vulnerabilities linked to Broken Object Level Authorization (BOLA) and Broken Object Property Level Authorization (BOPLA). Review the API Security Testing Checklist to learn about the multitude of test scenarios Aptori can seamlessly automate.

Aptori aids teams in rapidly releasing secure applications by autonomously generating and executing extensive tests that validate the authorization policy. This ensures that vulnerabilities don't escape detection, maintaining the security of your application.