Applying Minimum Viable Security to APIs

From Security standpoint, exposing Application functionalities as APIs means increasing the attack surface. The APIs are like to adding windows to a house, we know the doors usually are secure and being monitored in houses, however new windows might not be built with security in mind. Well, in this post I’ll explain how to check the security of your APIs and make it more secure according The Minimum Viable Security, following Pareto Principle and Shift-Left Testing approaches.

Some time ago I had the chance to speak (in Spanish) about Securing API lifecycle through the CI/CD, with that experience, I’m going to share the technical details on how to apply Minimum Viable Security to Application’s RESTful APIs, specifically how to implement SAST, SCA & DAST using opensource tools. To do that, I’ll use MAC Address Manufacturer Lookup python service.


Security along the APIs lifecycle

Software Development Life Cycle (SDLC) is an interable process with a sequence of stages that Engineers follow to gather requirements, plan, design and build Systems, Applications and/or Software. From Security point of view, we, the Security Specialsts, use different Security best practices and tools in each stage to make the end product (software) more robust, secure and reduce its defects and security issues.

The SDLC is more or less used to build any kind of software, on cloud, client/server, docker-based, blockchain-based, etc. That said, exposing a set of Application functionalities as RESTful APIs mean extending its features only, and doing that doesn’t require a new SDLC, because the process stages will not change. The only thing we will need is extending our CI/CD pipelines by adding the right approach to check the security of newly RESTful API artifacts added to our Application stack.

From Security standpoint, exposing functionalities as APIs only requires extending CI/CD pipelines and adding security checks in SDLC key stages.

Using the Pareto Principle and Shift-Left Testing

I’ve borrowed both approaches to outline what I want for Minimum viable Security, while Pareto Principle helps to focus on what to test and what testing technology will be used on specific software artifacts, the Shift-Left Testing recommends where those tests in SDLC stages will be implemented, considering limited resources, budget, time and maximizing the security outcome. With that, the SDLC stages and Security Controls are:

Implementing Minimum Viable Security in APIs Projects

SDLC Stage Security Control Tool options
02. CODE SAST, Config Drift SonarQube, Bandit (Python), Spectral (OpenAPI spec).
03. BUILD SCA Trivy, OWASP Dependency-Check.
07. OPERATE WAF Apache APISIX with Coraza WAF or Chaitin SafeLine.
08. MONITOR Logging APISIX with ELK, Loki, Prometheus, Grafana, etc.

With this and considering the MAC Address Manufacturer Lookup python service, we could reduce the above list and have this:

1. SAST for Application

The Service is implemented in Python, using a SonarCloud free account is enough to scan statically the Python code in entire repository. You can run scan for vulnerabilities in your code easily with SonarCloud by integrating it with your Github repository.

2. SAST for APIs

The Service is exposed as RESTful API, we are using the APIFlask Python library to generate the OpenAPI specification and documentation. I’ll use the Spectral CLI as an API style guide enforcer and linter. It will require a set of rules to enforce the security, in this case the OWASP API Security Top 10 (2023) and the Spectral OWASP API Security Ruleset are suitable to check of security of these APIs.

3. SCA

The MAC Address Manufacturer Lookup service uses Python libraries, a Dockerfile to build the application, a Docker Image based on Linux Alpine with a pre-installed Python environment to ship the application and its configuration, and since all source code, configuration files, Dockerfile, etc. are included in a single public Github repository I will use only a single tool to take care of everything in one single shot. The right tool to do everything is Trivy.


Conduct Dynamic Application Security Testing (DAST) requires the application is up and running, and an appropiate tool to scanner all web interfaces exposed for this application. The recommended tool to do this is OWASP ZAP. It works as a web proxy where we can automate the execution of many different tactics to find gaps and bugs in the applications. ZAP provides extensions and scripts to scan the security of APIs. The next guides explain how to do that:


5. Web Application Firewall (WAF)

Once the Application has been deployed, an way to protect it when it is up and running is using a WAF. You can install and configure a WAF to catch the incoming traffic before hitting the application, however this requires re-configure the application and re-route the traffic through the WAF.

To make easier everything and since our Application exposes APIs, to do everything in the API Gateway side. With that, changes in the Application side and re-route the traffic will not needed. Generally, the API Gateway supports making these changes and configurations.

The combination recommended for that is APISIX as API Gateway and Coraza as WAF. Next guides explain very well how to accomplish that:

APISIX and Coraza WAF

6. Observability

Observability is important in Security. If we don’t know what is happening with my application, we can not make decisions to enhance the security and the health of my application. As stated before, an API Gateway makes easier manipulate the traffic and integrate with 3rd party services. If we want to monitor the activity and performance of my running application and its APIs, then we need collect all log events and analyze that activity.

That’s why I’ve fallen in love with APISIX. It provides easier mechanisms to integrate monitoring services such Log Indexers, Log SaaS, Tracing, Metrics Monitoring, etc. Next guides to implement observability (security monitoring):

API Observability with APISIX


  • Adopt API First approach, it allows you be aware what functionalities and services are being exposed and should be protected and monitored. Using an OpenAPI spec file you can automate the security checking from your CI/CD pipeline. This is the first thing you should deal when implementing APIs.
  • Consider an API Gateway as part of your Application stack. The API Gateway will make easier the thing about security be implemented, specifically advanced security cotrols like Runtime Protection through WAF and Security Observability.
  • There are many things to secure when building Applications and APIs, but if you have release faster with a good level of security, then embrace the Minimum Viable Security approach and implement it using opensource tools. For more security tools, I’ve created this list for you: