BLST/CherryBomb case study

Stop half-done API specifications

BLST/CherryBomb case study

What is BLST/CherryBomb?

In recent years, applications have been moving from a monolithich architecture to a micro-service based architecture which means a lot of APIs are being used. As with any piece of software, APIs have their own set of vulnerabilities that developers have to account for.

Now there are tons of tools to test for security vulnerabilities in APIs such as Postman, SoapUI, Apache JMeter, etc. But what if the API logic is flawed? How will you fix a security risk if you, the developer, forgot to implement a proper verification method or overlooked that one minor logic error that could be catastrophic?

This is where CherryBomb from BLST security comes into the picture. CherryBomb is an open-sourced tool that checks your API business logic against OpenAPI specifications and tells you if your API has any logical flaws, and where you can find them.

What's the need?

Before we take a look at why we need a tool to ensure that API logic is sound, let us first look into how an API works.

API and how it works

You've probably heard the term API being thrown around a lot. Even as a non-developer, you probably have heard folks talk about APIs. In the simplest terms, API connects two or more applications together. An easy example to understand would be a restaurant.

Let's say you are in a fancy 5-star restaurant and want to get some food. How do you do it? You give your order to the waiter, who then gives it to the chef. The chef prepares the food, and the waiter brings the food to your table.

You've seen the above scenario countless times. But how will that help you to understand APIs? Think of it this way. You are one application, and the chef is another application. The waiter is the API in this case.

In the above example, the waiter(API) follows some set rules. The rules are something like this:-

  • Take the customer's order.
  • Ask the chef to prepare the order.
  • Wait till the order is ready.
  • Deliver the order back to the customer.

Terror of logic error

Now let's look at this from a developer's point of view. This means that only the laid-out instructions will be followed, and the API will not do anything apart from the instructions. If you look at the above workflow, there is one major flaw in it. Take a moment to think what's the flaw.

For ease of understanding, let's say that customer A has placed an order.

We never told the API what to do, if a third party came in and said "Hey waiter(API), don't give this order to customer A. Instead give this order to me." If this instruction was given to a human, of course, it wouldn't work. But since APIs work only with clearly defined rules, it is possible that the above instruction would be followed. Now think what would happen if something like this happened in a banking system. Needless to say, a lot of people are going to go broke if this happened with an API connected to a bank.

In a nutshell, business logic errors are potential loopholes that can be exploited if discovered. You don't want such loopholes in a banking system.

How CherryBomb solves the problem

You may have heard about OpenAPI Specifications(Previously known as Swagger Specifications) and Swagger. Let me make this easy to understand, OpenAPI is a set of rules and specifications meant to design secure APIs, and Swagger is a tool to follow through and build on those specifications. Are we clear on this? Let's move ahead.

While you are creating APIs, using the OpenAPI Specification (OAS) can help you to reduce some of the business logic errors which we talked about earlier. To implement these specifications, you have an OAS file. While you are designing your APIs you can create your own set of rules which are defined in this OAS file. Since these rules are written manually, you are prone to overlook some cases. The overlooked cases could end up being the biggest security risk in your API.

CherryBomb however, has a lot of pre-defined checks in addition to the OpenAPI Specifications. During your design phase, it will take in your OAS file, run a series of checks on it to make sure it is on par with the OAS, and output a detailed table with the information on security risks and their severity. Now moving on to integrations, CherryBomb will run some checks here to test your API implementations - is my API working as expected? Any unexpected behaviors? - before moving over to the production phase.

In the production phase, CherryBomb ingests your HTTP logs and builds a business logic map of your API. What this does, is it lets you see if there are any anomalies or misuse cases that may have been overlooked during the design phase. CherryBomb also tells you exactly where to look in order to fix the anomaly.

What is the Unique aspect of CherryBomb?

Most API security tools look at external security factors such as rate limits, SQL injections, etc. CherryBomb, on the other hand, looks at internal vulnerabilities of your API i.e the business logic implementation. We discussed earlier in this article why you need to look out for logical errors. If you are still skeptical about it, here is a perfect real-life example of how the tool has helped in preventing a logical error that would have had a critical security error.

Disaster averted thanks to CherryBomb

You know that a testing tool is good if the tool finds errors in itself. CherryBomb is no expectation to this rule. In a interview with Guy Levinger, CTO, Co-Founder at BLST Security, he shared about a logical error in the tool, which was detected by CherryBomb itself.

"We almost had a near-fatal error that might have reached production unless we used our own product on ourselves."

CherryBomb runs on AWS, which requires you to define a custom authenticator function. One of the developers forgot to implement an authenticator gateway. Thankfully, CherryBomb worked its magic and detected this before it was deployed in production. The error only took two lines of code to fix.

"During the process of testing the OpenAPI spec we quickly discovered it, and quickly fixed it."

In case this API was deployed into production, it could have been very devastating. Anyone could have hijacked the API and stolen sensitive data. From Guy's own experience, without a tool like CherryBomb, finding this error could have taken days, if not weeks or months. You can imagine the damage that could happen in that period of time.

"It took two lines of code to fix that mistake and would have been devastating if this API reached production, and we wouldn't know where the error is as quickly as we did."

Who is this tool meant for

CherryBomb primarily focuses on SaaS companies, E-commerce, Fintech, and retail markets. You can guess why something like CherryBomb is critical for these markets since they all heavily use APIs for functioning, and such a loop-hole in the API logic can be devastating, not only to the company but for their customers as well.


CherryBomb is a very useful tool to have, especially in today's world, where most applications are based on microservices and faulty logic could compromise the entire organization. CherryBomb can help you to secure and easily document your APIs, avoid any unwanted behaviors and avoid costly fixes by shifting left in the early stages of development.

Since it is open-sourced, you can get involved and help improve the tool to cover more and more cases.

Getting involved

Do you have some ideas about how CherryBomb can be improved? Check out the links below to get involved with the development of CherryBomb.

Did you find this article valuable?

Support WeMakeDevs by becoming a sponsor. Any amount is appreciated!