The Fourth Pillar of API Security — Testing

In my previous three posts, I talked about the need to discover and analyze APIs as well as remediate the vulnerabilities and other issues identified. Like these first three pillars, testing should not be a “one and done” exercise. In fact, it needs to span the entire software development lifecycle.

So let’s start at the beginning…

Every application starts with an idea, concept, or requirement. Before the first line of design work is written it is smart to be thinking in terms of how testing will be completed and how success will be measured. When most people think of testing in these terms, they are thinking about functionality testing. Can the system multiply these numbers with enough accuracy? Does the application deliver the data in a way that is usable? Does this application meet the original need? Will the application hold up under a heavy load?

When we break this down into smaller pieces, we often need to test every subfeature and maybe even every line of code. The process is grueling. Then, we add security testing — this is a completely different mindset as it doesn’t care about the intended purpose of the application. Security testing wants to know if the application can maintain confidentiality, integrity, and availability: the cybersecurity triad. Looking at any application from a 360 degree perspective, this is a massive undertaking.

Consider applying just confidentiality to a typical mobile banking application.

Confidentiality is critical in a banking application as nearly all the information accessed is considered sensitive: account numbers, names, birthdays, passwords, amounts, and so on. Proper testing ensures the confidentiality of all these sensitive data items is protected both in transit and at rest on or through every device in the data’s path.

Encryption is the key to confidentiality! Right? Wrong! While encryption plays a key role in keeping data confidential, and is responsible for rendering the data unreadable by the unauthorized, it does not guarantee confidentiality. By 2021, we should all know that the little lock by the URL in your browser indicates your information is encrypted when transmitted between the server and your local computer or mobile device. This is great, but it doesn’t mean your data is completely secure.

Consider Broken Object Level Authorization or BOLA. BOLA is the number one issue in the OWASP API Security Top 10, and for good reason. When authorization is not effectively checked, an authenticated user can gain access to data for which they are not authorized.

Let’s use a simple example to explain. 

When you check into a hotel, you present the desk clerk with a credit card and driver’s license. You are now authenticated, and in return, the desk clerk provides you with a room key that grants access to your hotel room. If that same key were to grant access to other guests’ rooms this would demonstrate broken object level authorization.

When this happens in the context of a web or mobile application, the user is authenticated, granted access, and the communications are encrypted (hence the lock on the URL), but the user is still able to gain access to other user’s data resulting in confidentiality being broken.

This is why testing is so important. Effective testing can identify issues like BOLA before the API is deployed to operational systems.

What about systems that are already deployed?

Testing on operational systems can be tricky. You don’t want to create problems by testing operational systems, but you also don’t want to stop testing an API just because it has been deployed to an operational environment.

How the Noname API Security Platform can help

Most organizations developing APIs have begun the process of “shifting left”, moving much of their security work to the earlier stages of development and testing. As a result, it is common for these companies to have staging or test environments. The Noname API Security Platform supports the software development lifecycle or CI/CD pipeline in many ways. One of the most important is the ability to identify an API in production, copy the schema as it is being used, and write the schema to the staging environment so that it can be tested in the same manner it is being used.

The Noname API Security Platform is uniquely capable of identifying all APIs in production without the use of agents or sidecars. In addition, it is the only product that also provides real time analysis of those APIs and the ability to test those APIs exactly as they were deployed, which is often very different from the way they were designed and developed.