API microservices have become a mainstay in the world of internet architecture. Roughly 31% of all the requests seen by Akamai are related to APIs which in turn has led to a tremendous increase in API attacks. In 2023 alone, Akamai saw a 2.5x growth in web application and API attacks.

As a cybersecurity professional, it is my mission to educate developers when possible on the risks that developing and managing API microservices can bring with them. In the last 18 months, I have written a series of blogs on 'the Fundamentals of API Security' which share the most common API security risks from a theoretical perspective.

But how does one put this into practice? What are the possible solutions to increase the security of your API? During the software development life cycle (SDLC), security should be thought of in each phase possible. But none of these bring more potential with them than the 'Test' phase.

Data is key, actionable intelligence is critical. Knowing exactly which security vulnerabilities can be used on your API stack is the perfect start on improving your security posture. Not knowing what is insecure is a risk in and of itself which brings us to the main topic of today, API security testing.

Want to know my preferred method of API security testing immediately? Click here.

API landscape of tools, technologies and platforms - courtesy ofAPI Landscape.

The world of API tooling is vast, there are hundreds of open-source tools and vendors out there which can help you with API testing in a variety of ways, focusing on specific areas. To help make sense of it all, in essence, API security testing boils down to four categories of 'Application Security Testing' (xAST):

Static Application Security Testing (SAST)
Dynamic Application Security Testing (DAST)
Interactive Application Security Testing (IAST)
Run-Time Application Security Testing / Self-Protection (RAST, also known as RASP)

Each of these categories bring specific benefits with it and as always with security practices, one isn't particularly better than others but requires a layered approach of applying multiple techniques to enhance your security posture.

Let's break down SAST, DAST, IAST, and RAST in simple terms using the analogy of running a fine dining kitchen. (I have been watching too much The Bear recently.)

Imagine reading a food recipe before cooking to identify any potential issues with the ingredients or instructions. This is what SAST does. SAST (Static Application Security Testing) analyzes the source code of an application without executing it. It looks for vulnerabilities, security flaws, and potential weaknesses in the code itself.

Now think of a taste tester trying a dish to find out how it actually tastes and if there are any issues with the final product. DAST (Dynamic Application Security Testing) assesses a running application from the outside, interacting with it like a real user. It simulates attacks by sending requests and observing the responses to identify vulnerabilities that may arise during runtime.

Next category is like having a chef observe and taste the dish as it's being cooked to catch potential issues. IAST (Interactive Application Security Testing) combines elements of both SAST and DAST. It assesses the application in real-time during its execution. It monitors the application while it runs, identifying vulnerabilities by analyzing both the source code and the runtime behavior.

Finally, picture a vigilant security guard stationed at the kitchen, actively preventing any harmful actions while the cooking is ongoing. RASP (Runtime Application Self-Protection) is a security layer integrated into the application, actively protecting it during runtime. It monitors and analyzes the application's behavior, and if it detects a potential threat, it can take protective actions like blocking the malicious activity.

To sum up, SAST reviews code pre-execution, DAST tests applications in runtime, IAST combines both approaches in real-time, and RASP is a proactive security measure integrated into the application during runtime, collectively enhancing software security.

Alright, while I mentioned that each of these methods are important and viable to increasing your security posture, having spend time with each of these methods, assessing tools and consulting companies that employ their own API security strategies, I definitely have a favorite method and I will break it down, tournament-style.

Round 1: SAST vs DAST

SAST (Static Application Security Testing):
- Strengths: Early detection of vulnerabilities in the code itself, ability to find issues before runtime, integration into the development process.
- Weaknesses: Limited coverage of runtime scenarios, potential false positives.
DAST (Dynamic Application Security Testing):
- Strengths: Real-world testing in a runtime environment, identification of issues that may only appear during execution.
- Weaknesses: Limited visibility into the code, may not find certain types of vulnerabilities.

Winner of Round 1: DAST

Round 2: IAST vs RASP

IAST (Interactive Application Security Testing):
- Strengths: Real-time analysis during runtime, combines benefits of SAST and DAST, potential for more accurate results.
- Weaknesses: Resource-intensive, may have some blind spots.
RASP (Runtime Application Self-Protection):
- Strengths: Active protection during runtime, immediate response to threats, integration into the application.
- Weaknesses: Dependent on the effectiveness of its protective actions, potential false positives.

Winner of Round 2: IAST

Final Round: DAST (Winner of Round 1) vs IAST (Winner of Round 2)

DAST:
- Strengths: Real-world testing, runtime environment coverage.
- Weaknesses: Limited code visibility, potential false negatives.
IAST:
- Strengths: Real-time analysis, combination of SAST and DAST benefits.
- Weaknesses: Resource-intensive, potential blind spots.

Grand Champion: DAST

In this imaginary showdown, DAST emerges as the ultimate victor.

Real-world situations being tested typically brings the best results with it. This makes sense when you are managing your API microservices and want to understand what could happen and what is happening to your APIs when running them in a production environment and if they are running live over the public Internet accessible to all.

So where can you go from here?

It all starts with assessing your current situation in the world of API security testing. Discuss with your development team what is currently in place in terms of tooling and policies and how your APIs are being tested outside of security as well (functional, regression, load testing etc. are all very important and helpful but limited to testing the security vulnerabilities.

Next, for those who want to learn more about API Security Risks, take a look at my video series 'The Fundamentals of API Security', 45 minutes which break down the common API security vulnerabilities.

With that in mind, I can also highly recommend to take a look into Akamai API Security. Akamai API Security gives you full visibility into your entire API estate through continuous discovery and monitoring. It conducts a risk audit of every discovered API, identifies common vulnerabilities, and uses behavioral analytics to detect threats and logic abuse within this fast-growing attack surface.

I have worked with several amazing companies worldwide to help improve their API security posture and Akamai API Security has given their developers this full visibility with which can be a great starting point on improving the testing procedures and policies because 'the more you know, the more you can protect'.

In the near future, I will share more hands-on tips and best practices around API security testing and how to tie this into your DevSecOps pipelines with automated tooling.

Of course, if you are looking for help with your API security posture, get in touch and I am happy to help!

Security Level Up

Security Level Up

Testing APIs, from a security angle...

...because although it works, it might not be safe.

Grand Champion: DAST