Using the Trace Analyzer

The APIClarity trace analyzer helps detect API security weaknesses in observed API traffic and provides a score for the severity of any detected weaknesses (low, medium, high). This functionality was described in detail in a previous blog, but for a quick refresher, the trace analyzer scans API traffic for: 

• Weak basic authentication 
• Weak JSON web tokens 
• Sensitive information (such as Personally Identifiable Information or PII) 
• Guessable object IDs 
• Broken Object-Level Authorization (BOLA) 

You can configure some of the things that the trace analyzer scans for, such as dictionary matches and regex rules for matching sensitive PII. There’s also a way to ignore findings if desired. 

Let’s take APIClarity for a spin and see the trace analyzer in action! 

Behind the Scenes 

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

For this blog, Sock Shop is up and running, and I’m generating traffic to it using Locust, as described here. I’m using the default configuration for the trace analyzer. 

Getting the Trace 

Good news – the trace analyzer is always running when APIClarity is configured to observe API traffic. Once APIClarity records the API traffic, it is run through the trace analyzer to scan for any potential security weaknesses. 

You can see the results from the trace analyzer in the APIClarity UI either aggregated at the API endpoint level or at the API event level.   

To see it at the API endpoint level, go to the API Inventory tab on the left in the Dashboard UI (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). 

On the next screen, select the “Trace Analysis” tab. 

If there are any trace analyzer findings, you’ll see them listed, along with a risk level (low, medium, high). In Figure 4 below, APIClarity reports four findings for the catalogue API: two potential Broken Object-Level Authorization (BOLA) weaknesses, and two matches on sensitive information, or PII. 

The Non-Learnt Identifier (NLID) finding is reporting a potential BOLA problem because an object ID was found in a request, but it was not retrieved first from the application. This could indicate a hacking attempt to guess the ID. You may recall from a previous blog that we saw a BOLA issue in the APIClarity spec difference listing for the catalogue API. That’s what the trace analyzer is reporting here (Figure 5). 

The “matching regular expression” findings (Figure 6) indicate that certain key words and patterns were found in catalogue API calls. In this case, the matches were the words “IBAN” (International Bank Account Number), “telephone number”, and what was presumed to be a server name. These findings are identifying a potential PII data leak. 

To drill down on the details of a particular API call that is getting flagged for issues by the trace analyzer, take a look at the API Events listing (third tab on the left in the dashboard UI, Figure 7). 

In the “Alerts” column, you’ll see a red “TRACEANALYZER” alert if there are any findings (circled in green in Figure 8). I’ll click on one for the catalogue API.

In the event detail UI, click on the “Trace Analysis” tab (Figure 9).

The red triangle symbol indicates there was a finding:

This will pull up details about the trace findings, similar to what we saw at the API endpoint level, but now for this specific call (Figure 10). 

Conclusion

That’s the APIClarity trace analyzer in a nutshell. It will help you secure your cloud-native APIs by watching them in action and reporting potential problems. 

Next up in the blog series – using the APIClarity BFLA detector! 

---

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