Using the BFLA Detector in APIClarity for better cloud native application security

The APIClarity BFLA detector helps detect unauthorized access to functionality in a cloud native application. We introduced the BFLA detector in our APIClarity overview, but for review: 

• BFLA is an API security term for Broken Function-Level Authorization in protecting a cloud native application
• BFLA issues can lead to security breaches and sensitive data leaks if exploited 
• BFLA breaches are on the rise 

The BFLA detector has two phases: a learning phase and a detection phase.

During the learning phase, the BFLA detector builds an authorization model based on observed API interactions between services. The user can mark any learned interactions as illegitimate if needed (interactions are assumed to be legitimate during the learning phase).

During the detection phase, the BFLA detector compares API interactions with the model to detect unauthorized access to functionality. Any API calls deemed “illegitimate” will be flagged and reported to the user via the UI. Note that BFLA detection is resource-intensive and needs to be explicitly started and stopped. 

Let’s try out the APIClarity BFLA detector! 

Behind the scenes of APIClarity

Throughout the APIClarity blog series, we’ve been using Sock Shop as our sample microservice application. See the APIClarity installation blog for specifics on the setup. 

For this blog, Sock Shop is up and running, and I’ve uploaded the OpenAPI specification for the catalogue service (see the OpenAPI specification upload blog for details on how to do this). I’m generating traffic to Sock Shop using Locust, as described in our APIClarity series overview. 

Building the authorization model 

The first step is to build the authorization model. 

From the APIClarity dashboard UI, go to the API Inventory tab on the left (second option, circled in green in Figure 1). 

In the API inventory list, select the one for your microservice application. In this case, we’ll select “catalogue.sock-shop” (circled in green in Figure 2). 

Next, select the BFLA tab (circled in green in Figure 3). 

To start the learning phase of the BFLA detector for the catalogue API, click the START button (Figure 4). 

After enough API traffic has been running to build up a model, stop the learning phase (Figure 5). 

The UI will then display the authorization model. The top-level is shown in Figure 6. 

If you drill down by clicking on the model, you’ll see a list of API endpoints with a shield icon next to each (Figure 7). 

The green shield means the API endpoint is considered legitimate: 

The red shield means it is considered illegitimate: 

Let’s select the “GET /catalogue/{id}” endpoint (Figure 7). 

For each API endpoint, you’ll see a list of services authorized to use the endpoint. For example, in Figure 8, the Sock Shop “front-end” service is allowed to use the “GET /catalogue/{id}” endpoint. Click on the arrow for details. 

Next, you’ll see details about the particular service with API authorization and about the endpoint. Here you can mark an interaction as “illegitimate” if it shouldn’t be allowed.  
For our purposes, I’ll mark this API interaction “illegitimate” so we can see APIClarity detect and flag a BFLA violation. I’ve clicked on “Mark as Illegitimate” (Figure 9). 

Now when we view the BFLA model, we can see the “GET /catalogue/{id}” endpoint interaction is labeled illegitimate with the red shield (Figure 10). 

Detecting BFLA violations

Now that the authorization model has been built, we can start BFLA detection (circled in green in Figure 11).  As mentioned, BFLA detection is not automatically running because it is resource intensive. 

We’ll next see a screen indicating that detecting is in progress (Figure 12). 

Now when calls are made from the front-end service to the “GET /catalogue/{id}” endpoint, the BFLA detector will flag them for BFLA violations (Figure 13). 

Select the API event that was flagged to get details, and then select the BFLA tab (Figure 14). 

This will show the BFLA violation in detail (Figure 15). 

This screen provides details about which service made the call, the endpoint that was called, and details about why it is considered a violation. Note that it’s possible to mark the interaction as “legitimate” from this screen if it’s actually allowed. 

Using the BFLA detector to enhance cloud native application security

That’s everything you need to know to use the APIClarity BFLA detection capabilities. But what is APIClarity for, and what can it do to meet your cloud native application security needs?

If you want to learn more about APIClarity, check out our post on APIClarity: Why now more than ever.

Anne McCormick is a cloud architect and open-source advocate in Cisco’s Emerging Technology & Incubation organization, now Outshift by Cisco.